Not defending cursors (I'm new to it all, including ClojureScript), but
someone has to play devil's advocate to your devil's advocate :)

<<
- their use can sometimes distort the way you structure you data.  Cursors
want you to layout data hierarchically (which often fine) but one day
you'll find yourself twisting your data structure so as to facilitate
Cursor use.
>>

Wait... are you saying that I can't have a transform function that
processes my data from the server before putting it into the atom? After
all, unless you have a BFF (backend for front-end) you'll almost always
need to transform your data for the view.

<<
- Cursors are simple extractors (which abstract away the path). But they
are not about "Derived Data" or "Materialised Views". They don't deliver to
your view a modified version of the data.  Yes, you can modify the data in
your view, but that means the view is doing too much.
>>

Again... the "view" doesn't have to derive, you can derive in transform
functions that can be used by any view and can be chained etc

So I'm still not getting it. Are you saying that cursors "encourage" rather
than "require" and going cursor-less provides less incentive for writing
bad code? I think writing bad code and cursors are two separate topics.





On Wed, Mar 4, 2015 at 1:15 PM, Mike Thompson <m.l.thompson...@gmail.com>
wrote:

> On Saturday, February 28, 2015 at 1:44:52 AM UTC+11, Erik Price wrote:
> > On Thu, Feb 26, 2015 at 7:55 PM, Mike Thompson <m.l.tho...@gmail.com>
> wrote:
> >
> >  The key thing for me is:  JUST. DON'T. USE. CURSORS. There I said it.
> They appear convenient, I know. They are a way of achieving reference
> transparency, I know.  But I think they are a “local optimum”.  Their use
> seems to get in the way of a more important data flow paradigm and they
> seem to encourage "control" into all the wrong places (components). At
> least that's my experience (I did try to love them, really I did :-)).
> >
> >
> >
> > I'm fairly new to Reagent, so as far as I can tell, cursors look great.
> But it sounds like you've run into situations in which they aren't helpful.
> Can you elaborate?
>
>
> Cursors are convenient. You'll get going pretty quickly with them, for
> sure.
>
> But if your app gets a bit bigger you might find some code smell starting
> to appear.
>
> - their use can sometimes distort the way you structure you data.  Cursors
> want you to layout data hierarchically (which often fine) but one day
> you'll find yourself twisting your data structure so as to facilitate
> Cursor use.
>
> - Cursors are simple extractors (which abstract away the path). But they
> are not about "Derived Data" or "Materialised Views". They don't deliver to
> your view a modified version of the data.  Yes, you can modify the data in
> your view, but that means the view is doing too much. Take a view that
> needs to show the top 20 items in a vector, when sorted by attribute Y.
> Now imagine that you have two views on the same data each with different
> sort criteria.  The underlying data can't be sorted two ways at once.  So
> the view will have to start doing the sorting.
>
> - the "write back" feature of Cursors is something I really don't like. As
> an app gets bigger, the control logic around updates gets more complicated.
> Using writable Cursors is a slippery slope towards more control logic
> getting put in the views.
>
> Overall, I find that Cursor use encourages you to make views do too much,
> know too much, which tends to be a problem as apps get bigger.
>
>
> --
> Mike
>
>
> .  make your use of Cursors easy, rather than modeling the right way.
>
> they can sometimes encourage you to structure your data in a tree-like way
> ... even though certain way.
> - The main problem I have with Cursors is that they are writable.
> I've found that they encourage control logic into views.  I prefer my
> views to be very passive.
>
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescript@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to