search

aaronc / freactive

High-performance, pure Clojurescript, declarative DOM library
http://documentup.com/aaronc/freactive
Eclipse Public License 1.0
387 stars 27 forks source link

Nested rx #20

Closed ul closed 9 years ago

ul commented 9 years ago

Suppose next case:

(rx (match @page
                   [:deck-structures nil] (deck-structures state)
                   :else (dashboard state))

we render different subtrees depending on current page. state is also reactive atom, which is used in some places of deck-structures and dashboard using another rxs, which become nested to one in snippet. This snippet will rerender entire subtree on any invalidation of state inside deck-structures or dashboard (depending on which one is current), but it is not desired. What is desired is to rerender entire subtree on page change, but rerender only rxed parts of subtree inside deck-structures and dashboard on state change. match page or match (rx @page) is another desired great solution, but it does not work, because match by itself is not dom node nor attribute nor style. Or may be I am missing something and there is another, right way, to achieve my goal?

Sorry that I'm spamming you with similar issues, but I'm trying hard to understand how to use freactive properly.

aaronc commented 9 years ago

So, nested rx'es is something that has occurred to me and I do intend to support this. I think it's actually not that hard - just need to think of the right place to insert it in the code...

If I understand correctly, you want something like (rx (match @page [...] (rx ... do something with @state))). I think one interim solution would be wrapping what you want to be nested in a div like (rx (match @page [...] [:div (rx ... do something with @state)])). Would that work temporarily?

And no worries about submitting different issues - I can't and don't want to do this alone so community contributions, feedback, etc. is very much needed and appreciated.

aaronc commented 9 years ago

Nested rx's should be very well supported in the current dev branch. Closing this.

ul commented 9 years ago

Yes, and there is a problem in this code https://github.com/aaronc/freactive/blob/develop/example/freactive/test1.cljs which I thought was an rx bug: 

item-keys (cursor state #(-> % :items keys))

must be

item-keys (cursor state #(-> % :items keys) #())

because cursor treats 2-arity second argument exclusively as korks. I think we should support read-only cursors w/o necessity to provide dummy setter.

aaronc commented 9 years ago

Yeah, so in the current cursor model, the one-arity version is for korks exclusively. The 2-arity version is for lens cursors, although the lens-cursor fn is preferred. Maybe I should just make cursor 1-arity to only take korks and lens-cursor 1 & 2 arity to avoid confusion. Would that work? Currently associative cursors and lens cursors are sort of different things thus the reason for cursor and lens-cursor.

When you fix the cursor issue, does your code work with nested rx's?

ul commented 9 years ago

Yes, nested rxs work fine. Regarding to cursors, I'm in doubt what will produce more consistent UX: to always use lens-cursor for lenses, or add a little bit more magic and check 1-arity argument type, and consider if it's function then user wants to build read-only lens-cursor, and provided korks otherwise.

ul commented 9 years ago

Maybe we should follow principle that explicit is better than implicit, and stick to different names for different types of cursor.

aaronc commented 9 years ago

Yeah, I'm leaning towards the explicit over implicit approach... less potential for surprises...

On Wed, Jun 10, 2015 at 12:19 PM, Ruslan Prokopchuk < notifications@github.com> wrote:

Maybe we should follow principle that explicit is better than implicit, and stick to different names for different types of cursor.

— Reply to this email directly or view it on GitHub https://github.com/aaronc/freactive/issues/20#issuecomment-110820047.

aaronc commented 9 years ago

I update freactive.core to reflect this explicit approach.

On Wed, Jun 10, 2015 at 12:26 PM, Aaron Craelius aaroncraelius@gmail.com wrote:

Yeah, I'm leaning towards the explicit over implicit approach... less potential for surprises...

On Wed, Jun 10, 2015 at 12:19 PM, Ruslan Prokopchuk < notifications@github.com> wrote:

Maybe we should follow principle that explicit is better than implicit, and stick to different names for different types of cursor.

— Reply to this email directly or view it on GitHub https://github.com/aaronc/freactive/issues/20#issuecomment-110820047.