-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restoring pull within q #21
Comments
Did the old version of Posh support pulls within q? I guess it let you do it, but didn't generate correct pattern matching for it. You might be better off with the old version for the time being. The new one is more advanced under the hood but we aren't taking advantage of the advanced features right now, plus I have yet to implement the |
There's some question here about what the Right Thing to Do (TM) is. To some extent, it would be nice if using pull in q actually return a reaction/ratom dereffing to a sequence of ratoms for the individual pull results. This would minimize the amount of rerendering and requerying. But would also be... rather weird. Conventional wisdom has it that you should never put an atom in another atom, because you're probably then Doing it Wrong (TM). But then again, that's generally for thinking about these things as storage/in-mem-db. With reagent, we're treating these things as more or less read-only (nevermind that as far as the implementation goes the reactions returned by Posh aren't actually reactions, but ratoms, and in theory could be written to from outside of Posh [SHOCK]). And the goal of reactions in general is to "gate" the flow of computation and rendering updates. So it sort of makes sense here... But still feels weird. In talking about it @mpdairy and I were never quite able to get over that weirdness and decide what the Right Thing would be. But maybe we should be bold, bite the bullet, and be crazy! We could always indicate that it's an experimental part of the API and that we'd love to hear feedback. In any case, hopefully thinking through this highlights why we've opted to recommend that users use separate pulls: It makes the optimal dataflow part of the problem obvious. But you're right. It is extra work, and it is annoying. Another idea: Maybe we let pull in q return a single reaction but expose a |
Absolutely love this idea
Fwiw I've already found myself using reactions in reactions so that I can
reset posh connections off local storage or exeternal persistence.
On Wed, Mar 1, 2017 at 2:46 PM Christopher Small ***@***.***> wrote:
There's some question here about what the Right Thing to Do (TM) is. To
some extent, it would be nice if using pull in q actually return a
reaction/ratom dereffing to a sequence of ratoms for the individual pull
results. This would minimize the amount of rerendering and requerying. But
would also be... rather weird. Conventional wisdom has it that you should
never put an atom in another atom, because you're probably then Doing it
Wrong (TM). But then again, that's generally for thinking about these
things as storage/in-mem-db. With reagent, we're treating these things as
more or less read-only (nevermind that as far as the implementation goes
the reactions returned by Posh aren't actually reactions, but ratoms, and
in theory could be written to from outside of Posh [SHOCK]). And the goal
of reactions in general is to "gate" the flow of computation and rendering
updates. So it sort of makes sense here... But still feels weird. In
talking about it @mpdairy <https://github.com/mpdairy> and I were never
quite able to get over that weirdness and decide what the Right Thing would
be. But maybe we should be bold, bite the bullet, and be crazy! We could
always indicate that it's an experimental part of the API and that we'd
love to hear feedback.
In any case, hopefully thinking through this highlights why we've opted to
recommend that users use separate pulls: It makes the optimal dataflow part
of the problem obvious.
But you're right. It is extra work, and it is annoying.
Another idea: Maybe we let pull in q return a single reaction but expose a
pullr which can be used in q and expands into the ratoms in ratoms thing?
That way, users can pick and choose, and if we realize reactions in
reactions *are* in fact a bad idea, we (and lib users) don't really have
to change the regular usage of pull, keeping things more stable (*grow*
software, don't change it, yada yada, praise be RH, our lord and savior).
Thoughts?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACljr1WgCpYaOBmO8ROi3xCTiyEANmBDks5rhTdsgaJpZM4MKgrZ>
.
--
Sent from Gmail Mobile
|
Would love to see pull in q queries with nested ratoms. |
Anything I can do to help on this? |
I don't think rules were ever properly solved. That's where we get closer to implementing our own Datalog I'm afraid. So I'd just help with that :-) I'm not really inspired to work on this at the moment with other things on the horizon, but if you want to hack something up, I can review and merge a PR. |
I personally just want to lobby for pulling back the pull within query
Especially when I'm in the early stages of figuring out a list component, I really like being able to use this to print out data from the entity, or entities that were returned in a tuple for a query
I'm finding myself very very frequently tempted to go back to the old version of posh to get this feature back.
The text was updated successfully, but these errors were encountered: