@val_waeselynck: Does this limitation not depend on whether or not you choose to pass the dependent values to the components in question directly or wrapped in the app-db atom? Or maybe I'm not understanding what you are saying.

@reefersleep: not sure I understand your question either

To me it's more that your components cannot be self-contained (they are statically connected to a global context), and that you cannot have a hierarchical organisation for event handling and / or state representation.

@reefersleep: I tried to express some of these ideas here: http://vvvvalvalval.github.io/posts/2015-09-16-bottup-approach-to-reagent-state.html

@val_waeselynck: the problem i always had with om's cursors was that some components ended up needing a blend of their own private context and some shared context, and you could do this by having a parent assemble a component's cursor, but the resulting object was a mutant half-cursor, which worked ok for reading from, but a component had to know which bits of the object were real cursors to be able to update without errors

@mccraigmccraig I can't really tell, I haven't used Om cursors :/

I have mostly used Reagent

i think my point is, that a single path into the global-state probably isn't enough for a component... and that if you are going to use cursors then they probably need to support more than just a single path in a better way than om's half-baked leaky-abstraction fashion

@mccraigmccraig I would think that Reagent cursors don't have this problem, since they have the same API as atoms

right, om-cursors do too, but the problem is an om component takes a single piece of data, and om-cursors have a single path... so if you want to give a component bits of data from multiple paths you have to give it something like {:a <cursor-a> 😛 <cursor-b>} which is a map with two cursor values, but the map is not a cursor itself, and the swap! / reset! ops don't work on it - the component has to know that it can only swap! / reset! on the values in the map

if your solution allows multiple cursors to be passed to the component, then that bypasses the problem

though i guess it introduces another problem, namely that the specification of the components data is no longer independent of the wider system

@mccraigmccraig: by 'your solution', do you mean what I proposed in the blog post ?

yeah

if so, yes, it allows for passing multiple cursors

I don't know about 'no longer independent of the wider system', to me the idea is just to allocate some portion of the state to a component, it does not need to have any assumption about the wider state, it's more like dependency injection

it really is 'just Reagent', nothing fancy here ^^

Hello guys, I have a simple (I think) question - do you transform data fetched by subscriptions handlers in handlers itself or transform it in views by some sort of helper functions? Thanks!

@ivanbokii: i seem to do most in the handlers, and mostly just do simple destructuring, conditionals and seq processing in the views

@mccraigmccraig: thanks. makes sense. I thought the right approach was to put all transformations in the handlers, but got problems with values comparison and unneeded re-rendering of my views.

ivanbokii: have you looked at chained reactions - https://github.com/Day8/re-frame#a-more-efficient-signal-graph

@mccraigmccraig: sure, it didn't work for me in a case when I need to produce a subseq from a sequence by filtering the original sequence and using reaction in anonymous func.

I mean deref reaction in an anonymous func in a filter call

also, if you produce a new structure in a handler based not on the data already stored in db but m.b. on something that you pass to the handler, that won't work either, since it will always be triggered and value comparison will fail in subsequent reactions

I hope it makes sense

well, i think i understand... though i've not encountered such problems - maybe someone else will have some suggestions

@mccraigmccraig: thanks for responding

@val_waeselynck: reading through your blog post, think I'm starting to get what you're talking about

@reefersleep: happy to discuss it

@val_waeselynck: Think I need to read up on some stuff before I'll be able to discuss it I'm not that experienced in reading ClojureScript, and the usage details of cursors is new to me.

*are