search

mpdairy / posh

A luxuriously simple and powerful way to make front-ends with DataScript and Reagent in Clojure.
Eclipse Public License 1.0
460 stars 45 forks source link

Restoring pull within q #21

Open Conaws opened 7 years ago

Conaws commented 7 years ago

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.

mpdairy commented 7 years ago

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 pull-tx and q-tx functions in the new version.

metasoarous commented 7 years ago

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 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?

Conaws commented 7 years ago

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 notifications@github.com 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 https://github.com/mpdairy/posh/issues/21#issuecomment-283286373, or mute the thread https://github.com/notifications/unsubscribe-auth/ACljr1WgCpYaOBmO8ROi3xCTiyEANmBDks5rhTdsgaJpZM4MKgrZ .

-- Sent from Gmail Mobile

den1k commented 7 years ago

Would love to see pull in q queries with nested ratoms.

Conaws commented 7 years ago

Anything I can do to help on this? Also, any suggestions on how we might get rules working again?

metasoarous commented 7 years ago

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.