feat(trees): add Vue adapter#652
Conversation
|
@onmax is attempting to deploy a commit to the Pierre Computer Company Team on Vercel. A member of the Team first needs to authorize it. |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85b356f3c2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (this.shouldRenderPreloadedTemplate && this.preloadedData != null) { | ||
| children.push( | ||
| h('template', { | ||
| innerHTML: this.preloadedData.shadowHtml, | ||
| shadowrootmode: 'open', | ||
| }) |
There was a problem hiding this comment.
preloadedData currently always pushes a <template shadowrootmode="open"> vnode during client renders, but declarative shadow DOM only attaches when the HTML parser sees that template in server markup. When this node is created via Vue on the client, hasExistingPreloadedContent() can still detect the template and route to hydrate(), even though no parser-created shadow tree exists, which can cause hydration against non-preloaded DOM (or avoidable mismatch/recovery work). The React adapter avoids this by rendering the preload template only when window is undefined, so Vue should apply the same SSR-only guard.
Useful? React with 👍 / 👎.
|
I'm curious if you have strong opinions about whether this should go directly in the library? On the one hand, AI can probably write decent vue code, and the wrappers are decently thin, but on the other hand, I know quite little about vue myself, so it's hard for me to evaluate whether I'm making good updates there. Would this be better served by a 'community adapters' section in the docs and a project that you or someone else like you maintains? |
|
I totally understand the concern. I can move this into a separate community-maintained package and maintain it myself, so the Vue-specific maintenance burden does not fall on you Would that direction work for you? My current thought is to keep it as a single package with a thin documentation layer, exporting the Vue adapter pieces from one place. Before I go that route, I would appreciate any concerns or recommendations about this direction, or anything else that would make this easier to reference from the Pierre docs as a community adapter. Happy to adapt the approach based on what would fit best on your side. |
|
that works for me. Once it's up I can link it in the official docs as well. We appreciate it! |
|
re: advice: I'd just stick as close as you can to a port of the react wrapper component as is reasonable in your framework. The key things to double check are that SSR and ssr + slot hydration work as you expect. (e.g. you can render a context menu that hydrates, or a header that is interactive). There's also a gotcha with hydration and our use of declarative shadow dom. Essentially declarative shadow dom is such that the dom that is eventually generated is different than the html that's shipped down the wire (without any js changing it, just by nature of DSD). So the hydration boundary needs to hydrate based on the eventual shadow dom situation, rather than the same markup it sent down the wire from the server. Which usually means you'll have to ignore hydration warnings. happy to answer any other questions or be generally helpful. |
2 participants
Description
Adds first-class Vue 3 support for
@pierre/treesthrough the new@pierre/trees/vueentrypoint. The adapter includes a Vue component, composables for selection and search state, SSR handoff throughpreloadedData, and a Vue browser fixture.The Trees docs now include Vue getting started and API pages alongside React and vanilla, plus updates to the integration and SSR guides.
Motivation & Context
Vue users can now adopt Trees without using the React wrapper or dropping down to the vanilla API. The adapter keeps the existing imperative
FileTreemodel as the shared contract, so core renderer behavior stays aligned across integrations.Planning to add support in Reka UI and Nuxt UI upstream as well :)
Type of changes
first discussed with the dev team and they should be aware that this PR is
being opened
You must have first discussed with the dev team and they should be aware
that this PR is being opened
How was AI used in generating this PR
Codex helped implement the Vue adapter, docs, tests, and review fixes under my direction. Also used codex to create a project inside
/tmpand verify everythign works in a brand-new project using@Browser useand tweak things.Related issues
None.
PS: I know this have a high cost for maintenance, but the other route I can think of is moving this code to Reka UI and support there instead. I am also planning to add a PR to add diffs support. Let me know what works for you. Thanks!