-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
Expose an API to preprocess the VDOM tree before diffing #2174
Comments
@petehunt recently released a repo for GSS https://github.com/petehunt/react-gss |
Exposing a hook does not seem preferable, making anything with global implications user customizable is generally not a good idea. What @browniefed linked to seems preferable or simply dissect and recreate the functionality in React, I imagine it would be quite possible to do the same thing in React and lose some "bulk". |
@browniefed: nice, hadn't seen that, thanks! @syranide: Yeah, I figured that it's not necessarily a change that anyone wants to make. I just had been playing around with the idea so wanted to see if anyone has any feedback, related ideas or plausible ways to achieve the same result. Thanks! |
Coroutines in Fiber (#6170) should make it possible to implement flexible layout primitives without breaking encapsulation. We won't go with the proposal in this issue. Thanks! |
One really positive feature of React is the ability to do proper logic for layout, e.g. you can do grids that scale both ways, take into account screen size and content size and so on. However, the reusability of such solutions is not often quite optimal.
There are solutions such as GSS that allow you to define things like this in a reusable manner, they're usually supported only in the most recent browsers (which would be easier to solve for React-based solutions, since virtual DOM doesn't depend on the browser) and also hooking them up to possible changes in the tree is tedious and hard to get right without sacrificing performance.
Allowing user-code to pre-process the virtual DOM tree before the diffing would open the doors for a whole new world of styling engines to born into, where reading from the virtual DOM tree is fast, as well as making changes to it. The implications vary from styling languages being able to define custom values such as
aspect-ratio
to apply a CSS aspect ratio hack, or inject extra DOM elements to make things centered based on theclassName
of the element, while keeping the user-code intent-oriented and clear, abstracting away the common pains of CSS.I realize that this is not a simple change of adding a hook somewhere, but instead means exposing a vast amount of API surface that's currently considered implementation details. This is also even more problematic in cases where
shouldComponentUpdate
is involved. However, I think this would have the potential to revolutionize how we deal with styling web pages, so I'd say it's worth thinking through at least.The text was updated successfully, but these errors were encountered: