Comments (5)
Thanks, for taking the time to go into this in detail. Most of what you witnessed makes sense to me. I didn't realize the DOM API's were so order dependent. It makes sense. It's just interesting that you could stumble on to that just using pure JS.
Basically the any given template the code generation looks like this:
- Clone template with all it's static attributes
- In JSX order for expressions and then children: create computations and set all values
- Return root element
From there the elements are attached and on value updates computations re-fire to update element values. Save from some nested chain dependencies (unlikely in this case, like value setting the max) updates should run again in JSX order. (EDIT actually I need to double check this).
React and Vue will not have this issue since they use Virtual DOM which will apply all updates in JSX order I imagine. The technique I use to initially render is a variation of what Google's lit-html and most Tagged Template Literal libraries(HyperHTML, lighterhtml, Haunted) use so I imagine they have similar issues. I will try to see how they look at this. But I'm yet to find any issues in their repos around this.
As you noted I should document that static attributes are all applied first in HTML parsing order.
from solid.
Yeah it looks like lit-html behaves the same way. I guess this is a problem inherent to this template cloning mechanism where static and dynamic parts are separated. The same mechanism WHATWG is trying to standardize for templating with Web Components. That's awkward. I wonder why I haven't seen this reported anywhere before for these libraries.
from solid.
I didn't have time earlier to see how others handled it but it looks like it came up and was fixed in React: facebook/react#7486. Vue has an open issue for it vuejs/vue#9515 and it sounds like they are suggesting users just ensure the order themselves. Vue's v-model
binding seems to get around the issue - it must run after the other attribute bindings.
I would now expect any UI library that sets DOM attributes would have encountered this issue or is vulnerable to it. Even with a virtual DOM setting the attributes is not atomic so somehow you have to decide which one to set first. Looks like React chose to ensure certain attributes are applied in a specific order. They also make sure to set type
first since it looks like there may be some quirkiness there too.
I'm not sure which direction you want to go, it appears there is precedent to handle it in the library or simply document it. I personally think it makes sense for the lib to handle it as writing JSX should feel like writing HTML where it doesn't matter in what order you specify the attributes on a tag.
from solid.
Yeah the challenge with template cloning is that you cannot even ensure the JSX(or Tagged Template Literal) order if you have a combination of static and non-static attributes. I'd have to not apply attributes statically at all which gets rid of a lot of the advantage. Otherwise as you said I could re-order based on name in the compiler. It feels a little loose in terms of consistency piece but I also get it's the type of issue no one would really realize.
Looking at the Vue issue, this apparently is a Chrome thing? I wonder if it's spec. Mostly in that as this template cloning approach I use is being actively worked on by people involved in setting the spec. And with this template cloning method it is impossible for me to retain template order for non-static parts. So unlike Vue or React there is no ability to even re-order the fields wholistically if I wanted to without looking into destroying benefits of template cloing. I think that is much too messy for the library to solve. Since Solid is so aligned with the Browser I hope that the Browser vendors figure out a way to address this. I'm looking to Google's lit-html or perhaps this specification to address this.
For now I agree this should be documented.
from solid.
Yeah, I guess the only thing you could do is rearrange the order of dynamic attributes but like you said, it could still lead to an inconsistent outcome for the user so documentation would still be required.
I just tried that example I linked in Edge and Firefox, both exhibit the same issue as Chrome. I didn't really see anything explicit in the HTML Standard but MDN suggests this is expected behavior
If an attempt is made to set the value lower than the minimum, it is set to the minimum. Similarly, an attempt to set the value higher than the maximum results in it being set to the maximum.
Anyways, documentation seems like the answer here. Feel free to close this issue.
from solid.
Related Issues (20)
- [Bug?]: hydration mismatch on ssr, and nested ternaries in jsx with objects or signals HOT 11
- [Bug?]: Missing interactivity on page refresh for @solidjs/meta Title HOT 1
- Events from inside web components with shadow root mode open have wrong target HOT 3
- Hydration Mismatch - createResource HOT 3
- Batch top level effects to make them behave consistent with regular effects HOT 1
- SVG attribute stdDeviation changes to lowercase when used with a reactive variable HOT 5
- `createMutable` intensive testing HOT 1
- Updating parent component state causes child to lose state HOT 4
- ref ins rsbuild failed HOT 3
- Exports from ./dist do not include corresponding type declarations
- strange hydration mismatch HOT 3
- Typescript - Components created via JSX "forget"/erase their type HOT 3
- Custom elements using `is` not recognized as custom elements HOT 3
- onCleanup is called on the server and it breaks the astro app HOT 1
- [Bug?]: SuspenseList hydration error HOT 2
- computations created outside a `createRoot` or `render` will never be disposed HOT 3
- [Astro] `createResource` results get mixed up when rendering server only components with Suspense HOT 4
- Hydration Mismatch error HOT 6
- [Bug] Repeated call syntax in JSX breaks reactivity HOT 1
- [Astro] resource and signal rendering is mixed up on the client HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from solid.