explain how it works in the readme?
Haroenv opened this issue · comments
Is your feature request related to a problem? Please describe.
When reading the readme, I don't understand how the variables with $ are special, and how they get detected by the framework. This would allow me to better know the limitations in extreme cases like proxies, third party objects etc.
Describe the solution you'd like
A section that explains the "how"
Describe alternatives you've considered
Could definitely be worded differently than "how", but in general the $ is only explained as magic in the readme
Additional context
I haven't used Rezact yet
Will do. Also working on a playground like svelte to be able to show what the compiler outputs.
Maybe for now it can already mention that there's a compiler/babel plugin(?) then?
Guess it's a compiling trick like
const $count = 0
return <div>{$count}</div>and transpile it to
const $count = ref(0)
return <div>{$count.value}</div>Acctually you don't need a "$" to tag which variable is reactive, you can analize the returned jsx to see which variable has been used.
@IanDxSSXX You are correct. The compiler is transforming the code similarly as you have shown.
And while I could analyze the returned JSX to see which values are being used and then transform them into the reactive versions, this has 2 downsides:
- Analyzing the returned JSX to make decisions about what should be reactive and what shouldn't is more work for the compiler than simply seeing a variable explicitly declared with a
$sign and transforming that. - Eventually, not having some explicit indicator in your own code of which variables are reactive and which one's aren't will bite you when it comes time to debug.
The choice to use the dollar prefix was very intentional. It makes it very clear to all interested parties (the dev, the reader, the compiler) that this variable is special and should be treated as such.
I believe this is why we are seeing Svelte move to rune's. There is value in explicitly declaring state.
The primary difference here is that I have opted to only force the use of a $ prefix. This covers a large swath of the use cases without the extra boilerplate of runes.
@zachlankton Thanks for your explanation! But I may differ a bit.
For the first point, with some optimized algorithms, the procedures to build such a "dependency chain"(that's what I called it, basically it's a graph like count -> doubleCount -> <div/>) won't be that costy.
And the second one, actually in the end of the day, there should not be a so-called state, they're all normal variables except there're specific ones that can cause the view to render. But as developers, we don't want them to be different. I declared a variable, if it's in the view, it should cause the re-render, if it's not, just leave it. The only buggy thing there could be is dependency loops. But this can certainly be avoided if you treats the dependency graph right.(basically cut the edge if you detected a loop).
There're a lot of details inside this strategy. There's a similar project like yours recently - alins. He basically followed the dependency graph philosophy but still a little bit more work out there.
And this is the framework I made with the dependency chain -- dlightjs. A lot different designs with current frameworks(now the new frameworks are almost functional components + jsx). Some new designs might be good, some might not. But I just want to explore it and break the box built by react.
Again, wonderful project!
https://github.com/Rezact/Rezact/blob/main/COMPILER.md
I'm closing this issue for now as the link above is a great start at explaining the underlying compiler mechanism. If necessary... let's start a discussion in the discussion tab!
Thank you all for the support!!