You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are couple of higher level design decisions that I feel are somewhat limiting, so if I were to make cljfx-next (I'm not), I would do these differently:
I would extend Lifecycle protocol to keywords and functions instead of relying on :fx.opt/type->lifecycle. This thing actually might be fixable in cljfx, but ensuring no breaking changes will be very difficult.
I would use namespaced keywords (instead of plain ones) for props, and would try to allow extension lifecycles be parts of component description they wrap:
;; so that this:
{:fx/type fx/ext-on-instance-lifecycle
:on-created prn
:desc {:fx/type:label:text"text"}}
;; would become something like this:
{:fx/type:label
fx/ext-on-instance-created prn
:fx.labeled/text"text"}
renderer abstraction would become "view description that has access to data" instead of "transformation from data to view description"
I would explore making lifecycles or their surroundings a transducer context. It would be nice to write (comp (dedupe) (fx/advance-lifecycle)) to skip same descriptions, and it might prove itself useful on other areas.
I would explore how to make it truly reactive instead of doing what react does, so when change happens, a system would know what exactly should be updated instead of doing "virtual dom diffing". See svelte.
Some problems I found that don't map well to cljfx/react model:
some props don't belong on any particular component: managing the focus between different components is "somewhere else".
inequality of prop values does not always mean reassignment of new value has to happen: event listeners are invoked when events happen, so they need to know their value only at a later point in time. Having the same event listener while the prop is set and looking up the latest value while the event is fired is more efficient.
The text was updated successfully, but these errors were encountered:
I have a feeling that mutators are just a different kind of lifecycle. Also, something like "memoize-latest-call" would greatly simplify all lifecycles.
There are couple of higher level design decisions that I feel are somewhat limiting, so if I were to make
cljfx-next
(I'm not), I would do these differently:Lifecycle
protocol to keywords and functions instead of relying on:fx.opt/type->lifecycle
. This thing actually might be fixable in cljfx, but ensuring no breaking changes will be very difficult.renderer
abstraction would become "view description that has access to data" instead of "transformation from data to view description"(comp (dedupe) (fx/advance-lifecycle))
to skip same descriptions, and it might prove itself useful on other areas.Some problems I found that don't map well to cljfx/react model:
The text was updated successfully, but these errors were encountered: