Skip to content

fix(runtime-dom): export nodeOps and patchProp for easier custom render creation #13753

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

stefanonepanedap
Copy link

@stefanonepanedap stefanonepanedap commented Aug 12, 2025

This PR exposes nodeOps and patchProps in order to facilitate the extension of web base custom renderers.

eg. Implementing scopedRegistry for custom component support.

Summary by CodeRabbit

  • New Features
    • Exposed additional runtime DOM APIs as named exports from the main module, allowing direct imports without deep paths.
    • Improves developer experience and tree-shaking by making low-level DOM operations and prop updates accessible through the public API.

Copy link

coderabbitai bot commented Aug 12, 2025

Walkthrough

Adds named re-exports for nodeOps and patchProp from runtime-dom’s index.ts, expanding the module’s public API. No runtime behavior or control flow changes.

Changes

Cohort / File(s) Summary
Public API re-exports
packages/runtime-dom/src/index.ts
Added named re-exports: export { nodeOps } from './nodeOps' and export { patchProp } from './patchProp'. No logic changes.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

I twitch my ears at exports new,
Two carrots—nodeOps, patchProp—debut!
No burrow re-dug, no flow askew,
Just clearer paths for hops to pursue.
Thump-thump! The API grew.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

  • Visit our Status Page to check the current availability of CodeRabbit.
  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
packages/runtime-dom/src/index.ts (1)

20-20: Document and track the new public exports

This expands the public API. Please:

  • Add an API/docs note that nodeOps and patchProp are available from @vue/runtime-dom for custom renderers.
  • Add a changelog entry (semver: minor).
  • Double-check d.ts output to ensure consumers without "dom" lib in tsconfig don’t hit surprising type errors. Given this is runtime-dom, it should be fine.

I can draft the changelog and a short docs blurb if helpful.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c875019 and a3e9d85.

📒 Files selected for processing (1)
  • packages/runtime-dom/src/index.ts (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: Redirect rules
  • GitHub Check: Header rules
  • GitHub Check: Pages changed
🔇 Additional comments (1)
packages/runtime-dom/src/index.ts (1)

20-20: Public API addition for custom renderers — LGTM

Re-exporting nodeOps and patchProp from the runtime-dom entry is a clean way to enable custom renderer composition without deep imports. No runtime behavior changes; size impact is negligible since both are already imported for rendererOptions.

@stefanonepanedap
Copy link
Author

@coderabbitai where can I add documentation?

Copy link

coderabbitai bot commented Aug 13, 2025

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, let's explore the repository structure to understand where documentation is typically placed
echo "=== Repository structure overview ==="
ls -la

echo -e "\n=== Looking for documentation directories ==="
fd -t d -I "doc" --max-depth 3
fd -t d -I "docs" --max-depth 3

echo -e "\n=== Looking for README files ==="
fd "README" --max-depth 2

echo -e "\n=== Checking packages structure ==="
ls -la packages/

echo -e "\n=== Looking at runtime-dom package structure ==="
ls -la packages/runtime-dom/

echo -e "\n=== Checking for existing documentation in runtime-dom ==="
fd -t f "README" packages/runtime-dom/
fd -t f "*.md" packages/runtime-dom/

Length of output: 4773


🏁 Script executed:

#!/bin/bash
# Let's check the existing runtime-dom README to see how it documents exports
echo "=== Current runtime-dom README content ==="
cat packages/runtime-dom/README.md

echo -e "\n=== Let's also check the main Vue README for documentation patterns ==="
head -50 README.md

echo -e "\n=== Check for any TypeScript declaration files that might contain documentation ==="
fd --glob "*.d.ts" packages/runtime-dom/

echo -e "\n=== Look at the actual index.ts file to see current exports and any existing documentation ==="
cat packages/runtime-dom/src/index.ts

echo -e "\n=== Check if there are JSDoc comments in nodeOps and patchProp files ==="
head -20 packages/runtime-dom/src/nodeOps.ts
echo "..."
head -20 packages/runtime-dom/src/patchProp.ts

Length of output: 13434


🏁 Script executed:

#!/bin/bash
# Let's check if there's a contributing guide that mentions documentation practices
echo "=== Looking for contributing guidelines ==="
fd "CONTRIBUTING" --max-depth 2

# Check the .github directory for any documentation guidelines
echo -e "\n=== Checking .github directory ==="
ls -la .github/

# Let's see if there are any existing JSDoc comments for similar exports in the codebase
echo -e "\n=== Looking for JSDoc patterns in similar exports ==="
rg -A 5 -B 2 "export.*{.*}" packages/runtime-dom/src/index.ts

# Check if there are any official Vue.js documentation repositories or links
echo -e "\n=== Looking for any documentation-related files ==="
rg -i "documentation|docs" README.md

# Let's also check what nodeOps and patchProp actually are
echo -e "\n=== Full nodeOps file to understand what it exports ==="
tail -50 packages/runtime-dom/src/nodeOps.ts

echo -e "\n=== Full patchProp file to understand what it exports ==="
tail -50 packages/runtime-dom/src/patchProp.ts

Length of output: 4871


🏁 Script executed:

#!/bin/bash
# Let's check the contributing guide to see if it mentions documentation practices
echo "=== Checking contributing guide for documentation practices ==="
cat .github/contributing.md

# Also check if there are any existing JSDoc comments in the codebase for reference
echo -e "\n=== Looking for JSDoc examples in runtime-dom ==="
rg -B 2 -A 2 "/\*\*" packages/runtime-dom/src/ --type ts

# Let's see the complete nodeOps and patchProp exports to understand their structure
echo -e "\n=== Complete nodeOps export structure ==="
rg -A 200 "export.*nodeOps" packages/runtime-dom/src/nodeOps.ts

echo -e "\n=== Complete patchProp export structure ==="
rg -A 50 "export.*patchProp" packages/runtime-dom/src/patchProp.ts

Length of output: 49742


@stefanonepanedap Based on my analysis of the Vue.js core repository, here are the recommended places where you can add documentation for the newly exported nodeOps and patchProp:

1. JSDoc Comments in index.ts (Recommended)

Add JSDoc comments directly above the export statement in packages/runtime-dom/src/index.ts:

/**
 * Platform-agnostic node operations for DOM manipulation.
 * Used internally by Vue's DOM renderer and can be used for creating custom renderers.
 * 
 * @example
 * ```js
 * import { nodeOps, patchProp, createRenderer } from '@vue/runtime-dom'
 * 
 * const customRenderer = createRenderer({ 
 *   ...nodeOps, 
 *   patchProp 
 * })
 * ```
 */
export { nodeOps } from './nodeOps'

/**
 * Platform-specific property patching function for DOM elements.
 * Handles class, style, events, and other DOM properties/attributes.
 * Used internally by Vue's DOM renderer and can be used for creating custom renderers.
 * 
 * @param el - The target DOM element
 * @param key - The property/attribute key
 * @param prevValue - Previous value
 * @param nextValue - New value
 * @param namespace - Element namespace (svg, mathml, etc.)
 * @param parentComponent - Parent component instance (for context)
 */
export { patchProp } from './patchProp'

2. Update the runtime-dom README.md

Enhance packages/runtime-dom/README.md with examples showing how to use the newly exported functions:

# @vue/runtime-dom

```js
import { h, createApp } from '@vue/runtime-dom'

const RootComponent = {
  render() {
    return h('div', 'hello world')
  },
}

createApp(RootComponent).mount('#app')

Custom Renderer Creation

The nodeOps and patchProp exports enable you to create custom renderers:

import { createRenderer, nodeOps, patchProp } from '@vue/runtime-dom'

// Create a custom renderer using DOM operations
const customRenderer = createRenderer({
  ...nodeOps,
  patchProp,
  // Add custom logic here
})

## 3. Inline Documentation in Source Files (Optional)

You could also add more detailed JSDoc comments in the source files themselves (`nodeOps.ts` and `patchProp.ts`), but since these are already well-structured, the export-level documentation would be sufficient.

## Best Practices

Based on the existing codebase patterns:
- Use standard JSDoc format with `/**` comments
- Include `@example` blocks showing practical usage
- Keep examples focused on the custom renderer use case (the main reason for exporting these)
- Follow the existing documentation style seen in other parts of the codebase

The JSDoc approach is most appropriate since it will appear in IDE intellisense and generated type documentation, making it immediately helpful to developers using these exports.

@edison1105 edison1105 added ready to merge The PR is ready to be merged. version: minor labels Aug 21, 2025
@edison1105 edison1105 moved this to Todo in Next Minor Aug 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready to merge The PR is ready to be merged. version: minor
Projects
Status: Todo
Development

Successfully merging this pull request may close these issues.

2 participants