zouloux / reflex-dom Goto Github PK

<Component children={ <Child /> } />

should be the same as

<Component>
    <Child />
</Component>

With the second one, no need for { props.children } in Component instance. It should be needed.

HMR does not keep states of children of swapped components.
This is because when re-creating tree, the child component is not added to the DOM, so the state cannot get DOM-path to retrieve its old value.

<div />
{list.map( e => <span />)}

Will not work.
All spans will be into the div.
Temp fix :

<div />
<div>{list.map( e => <span />)}</div>

Continuing discussion from this long thread :
zouloux/prehook-proof-of-concept#1

Answering @xdev1 :

@xdev1 : It would be really helpful, if the demos in reflex's README.md were written in TypeScript or at least a bunch of non-trivial examples.

True ! In fact, if this lib is used someday, I'll create a cleaner doc with categories, Readme.md will become a classic lib homepage with basic facts and pointing to the doc. For now, I'll keep it this way because it's still in beta and only used by me 🥸 I'll just create some code sandboxes so new users could play with it in plain TSX without having to setup an env.

@xdev1 : Also, using prettier would be very nice. Every syntax that is used with the reflex patterns should work fine with prettier, as a majority of developers (including me 😉) use prettier wherever possible.

Using prettier in the reflex/src ? Why not ! Again this is beta but I may accept to use prettier if I got others maintainers helping me. I'm not a huge fan on prettier on those kind of algorithmes, I often need manual formatting for better understanding. Also very opinionated but clearly not closed to prettier !

@xdev1 : I would consider, not to use the name hooks anymore if it's not "react-like" hooks. Folks will get confused otherwise (especially those who do not like react-like hooks, I know this from own bad experience in other discussions 😄). Maybe extensions could be a good name instead, as those functions are conceptionally extension functions where the first argument (= object) will just be passed implicitly.

Yep, I totally agree ! I was roaming into your https://github.com/js-works/preactive codebase recently and found the naming very interesting, I'll re-use this idea if you are OK 🙌 You are right about how things are named, this is very important for global understanding.

@xdev1 : One major goal for that factory-pattern based components should be to increase conciseness wherever possible and reasonable. In the old days we used stuff like this.props.label which was extremely cumbersome, React now uses just label which is awesome, while reflex uses props.label, which may look okayish first, but if you love React as I do and then you use reflex (or something similar), then even props.label seems way to noisy. I personally really prefer using the variable name p instead of props which reduces noise at a good amount especially in larger components. I know, normally we try to prevent single-character variables (except for maybe i, j, x, y etc.) but here this shortcut makes perfectly sense, IMHO. By the way, I'd also use s for a state object (i.e. s.count instead of state.count) and ctx for the used context values (i.e. ctx.theme).

I agree about how concise is React but I do not find this too much of a drawback. Solid has the same way of dealing with reactive values and props (as in a, object, not destructurable), and it feel fine when you know it. Will keep plain props in source code and examples because not everybody knows that p means props, and by extensions componentProperties. Also always destructuring objects into vars can be sometime noisy, a lot of curly braces to understand, which is fine for a lot of people but can be messy if done wrong. I'll maybe find a way to make defaultProps work with destructuring somehow (in stateless), if it's possible it will be implemented but I feel that stateful and stateless components should not work too differently. If any stateless component you are writing is becoming stateful for any reason, you should not be forced to refacto too much the code, it can be source of errors and frustration.

@xdev1 : Regarding stateless components: I would not provide some special API for those stateless components as it is not really necessary.

Stateless components are / will be very much the same as React functional components, but with the defaultProps and shouldUpdate functions, working like factory components. Maybe it will be through the preset and shouldUpdate extensions, which will work both in factory and stateless components. This can be easily explained in the doc + by raising errors in dev mode if misused.

@xdev1 : Frankly, I do not know, why count.set(count.value + 1) shall be better than setCount(getCount() + 1) or setCount(count() + 1) or count(count() + 1)

Yep that's pretty much the same BUT : Now states are usable both ways :

const myState = state( 0 )
state.value ++ // will trigger component update
// dom is not updated yet
await state.set( newValue )
// or
await state.set( v => v + 1 )
// dom is now updated and ready because of the await

Also, having state.value as a getter, will allow us to implement atomic rendering (diff only nodes that use this getter). It will have better perfs than React in a lot of cases and useState cannot do it because of value as a variable (not possible to track usages)
See @developit twitter thread on this : https://twitter.com/_developit/status/1549001036802625536

@zouloux : I'll search for a solution but the preset hook is maybe the only way to have this working in strict mode.

@xdev1 : The only type-safe solutions that I know are the following ...

@zouloux : I'm starting to like the preset version ! The HOC (curried) version feels more wrong to me because there is a lot of curly / destructuring / generic noise which can be avoided. It is less chars but it feels more to me ^^

}>({
  initialCount: 0
})((p) => {

As always, thanks for your time and your feedbacks ! You rock ! I'll try to re-read everything later because I'll get more subtleties. Also, I'm starting to use the lib on a personal project so I'll surely have some changes to do, will do better docs after this "alpha" phase is finished.

Needs to re-implement without module parsing.

Some attributes cannot be set as false from boolean values.

<img draggable={false} />

will not have draggable="false".

<img draggable="false" />

will have it, but JSX types are incorrect.

Solution :
In diffElement, check if value === false, then setAttribute(key, "false")

I made a little test how a Preact component behaves if you use both signal count and count.value in the same component.
Then I tried the same with Reflex and saw that Reflex has a bug in the signal optimization.

Please have a look at the following demo - both buttons should behave the same, but the Reflex button is not working properly:
https://codesandbox.io/s/rough-meadow-5piocu?file=/src/index.ts