@davewo @dnolen: Thanks for the info!

@drcode: port Om.Next to js? 😉

@thosmos: that wouldn’t actually be so hard, the most challenging bit would be what to do with the query part

I'm missing somewhere the idiomatic way to build up a query for only rendered components. I see two possibilities, both of which seem like I'm missing something easier: (a) extensive use of Query Params and manipulation of them or (b) Looking at current state and conditionally returning null for things that I know aren't being rendered.

a) is the one that naturally comes to my mind for me

if you think of queries like urls then it’s a natural place to put result size parameterization

Result size make sense, I'm thinking more binary. Like I'm looking at the dashboard, and the "chat" nav item has not been clicked. I don't want to load the chat data until it is.

right, Relay has a notion of delayed queries - but I wonder about that

seems like sugar for something easily expressed by just changing the query

there is an reading code advantage to the declarative aspect of having syntax for it ...

Yes, just changing the query seems perfect, but my inclination is to return just the parts I need from IQuery. However, I've observed IQuery is only called once, not at each render. At least that is what appears to happen. I'd want IQuery called each time, access om/props from within it and return a different query.

yeah we’re not going to do that

you can use life cycle methods to accomplish the same thing anyway

and you can write sugar over defui if you want this for all of your own components

OK, I'll explore that path for it.

This will be a common challenge for large apps that have deep functionality, much of which is infrequently accessed.

I don’t see any challenges here at all … only a challenge based on the way you to achieve this as far as I understand it

if somebody clicks a button, I would just change the query then and there

and avoid all this props talk

(dom/render-to-str (om/build some-widget data)) -- Would this would need to be done on the server?

dom/render-to-str is for server side rendering yes

Ok so that means even if I used Om with a different backend language I would still technically need JVM if I wanted to have a faster first page view and keep my SEO up

@grounded_sage: you would need a JavaScript engine, not a JVM

@bplatz: one way that’s more declarative is to put all the fragments you intend to use in IQueryParams

then you can see all the things that a component might add to the query

then when you change the query just add the var you need

So using om/set-query! within the context of a transaction sounds like your recommendation. That sounds good, only downside I see is that it separates where you can easily reason about what a given query might be.

Do I need a JavaScript engine to run it when I am using Clojure on the backend?

@bplatz that’s not even true

@dnolen that sounds like another good option.

not only do we log all transactions we log all query changes

all state transitions are copy pasteable / explorable

I was referring to the logic that determines what a query might be. Part of it would end up being handled in a function that is detached from the component itself. Your recommendation of using Query Params is a way to avoid that.

@bplatz: ah, yes I see what you mean and it’s clearer what your original question was about.

yeah I would use IQueryParams if I wanted to make it clear what types of queries a component might make

so of course working on recursive queries reveals things I do not like with current parse behavior

once you’re doing something recursive having to read from the atom only to rewrap a part of the atom to make a recursive call seems gratuitous

thinking that we should also pass :data key in addition to :state?

maybe :pure to constrast with :state but also make a correspondence?

I can't follow. Can you give an example?

So the :data key, if I understand it, would just be a map you pass in or similar?

One item that has bothered me is common query items that are repeated at many levels of the query tree, for example something like :user/language. Most components will want to know it, so it ends up sitting in, with my case, 2/3 of all components. Keeping with the purity of the parser, it is looked up with every recursion. I was thinking I'd optimize some of this with memoize as I figure out the implications.

(I'm using datascript, so in my case it is a datascript query that is executed)

right that’s a different problem

I’m not sure that real global information like that should be transported by queries

@bplatz the scaffolding for :shared is there, I would probably propagate this at the root

@jannis I need to think about this some more once I can actually express my dislike for how parse looks in this case I will

Ok

@dnolen :shared works great for these sort of environmental variables, thanks for pointing that out. If IQuery can be analogous to a REST request, :shared can be analogous to HTTP headers... a context.

@bplatz yeah I’m fixing up shared a bit now

will probably cut a release with this bit and the other recent tweaks

FWIW, at first blush :context seems a bit more descriptive of intention (or at least how my intention is of using it). Extends nicely to the idea of reusing code in different contexts, like React Native. Query defines data needed, context could modify behavior of the component.

@bplatz: it’s a little bit better but it’s pretty overloaded

in React it gets used for a lot of things

and in Om Next we already had this before it was ever public in React and we called it shared

@bplatz: https://github.com/omcljs/om/commit/dbecf8545e4b51cb6a78c3f9e8858d3609cd474e

there you go

the new thing needs some tweaks to account for remotes

so you can supply static :shared

as well as :shared-fn which will compute shared properties from the root props.

these get merged together.

and every Om Next component will see them.

Neat

Function is a nice addition. I'll have to look to see if the function is executed only on the first root render, or every props change.

But most things I think (should) be stored there are likely fairly static in nature.

@dnolen: reconciler docstring states all properties are required

probably a typo?

@anmonteiro: thanks fixed

@bplatz: it’s run every root render but this shouldn’t really be problem since the function should be side effect free.

Hi guys. I am still stuck in my first attempt. https://gist.github.com/leontalbot/1d57bb05c063a989757c

@leontalbot: that’s a lot code for what is as far as I can tell a very simple problem / misunderstanding

just make the tiniest possible thing demonstrating the conceptual issue you are having

if I can recall correctly I just don’t see how this isn’t solved by having

:questions [[:question/by-id 0] [:question/by-id 1]]

@leontalbot: can you explain why this doesn’t work for you ^ ?

You are right. I'll narrow down the problem tonight

i was surprised that om/computed clobbers any existing computed props, but i’m doing this within a union component so i may only be seeing the outlier case

@joshfrench: there’s no particular reason for the behavior we could merge instead

ordinarily you wouldn’t pass down the complete props wholesale except in the case of a union or a pass-through, right? i’m trying to decide if it would be weirder to find inherited props in om.next/computed or to have to manually reconstruct them at every level

well “inherited"

I think it’s important to not abuse the feature

accumulating stuff at each level just isn’t going to work

and if you’re doing that be ready for very weird bugs

for this reason the current behavior of clobbering maybe even the right one

and we should just document it

and people that want to play the dangerous game can do so knowingly

that’s my hunch, for all the cases where merging would be a reasonable convenience there are probably more where it’s a code smell

k I’ll document the current behavior and we’ll see how it plays out

👍

I could imagine merging computed to be quite confusing. Imagine A passing down a click-fn to a child B, which in turn has another child C that also allows a click-fn to be passed down. You could easily end up passing the root click-fn to both subcomponents by accident and weird things might happen.

If we don't merge, the click-fn will only be set in child C if it's explicitly passed down from B. I think at least for callbacks that's desirable.

Does this make sense?

I think it helps a lot if you have to assemble computed at each level. It'll be very explicit in each component, making it easier to understand what's going on.

yes, I’ve updated the docstring to clarify the behavior

Does anyone understand how creating new Todos work in David’s om-next-demo re: Getting the datomic generated Todo :db/id attribute back to the client? I can’t find anywhere where todos/create-temp is being transacted

@adamfrey: just never got around to do the temporary todo bits

exercise left for the reader so to speak

right, that’s where I am right now.

yeah the problem here is the temp id problem

I have a thing that works for part of the problem. In my resource creation, I’m pushing into the list new item, but with an id of :temp, which renders it to the screen. Then I kick off the :remote true transaction

then my client reads the list again and I modified my parser to have this:

(defmethod read :places/list
  [{:keys [state selector]} _ _]
  (let [st @state]
    (if (contains? st :places/list)
      (let [places (get-places st selector)
            has-temp-place? (some #(= (:db/id %) :temp) places)]
        (if has-temp-place?
          {:remote true}
          {:value places}))
      ;; First pull
      {:remote true})))

@adamfrey: yeah I thought about this some more I think this needs a standard solution

temp-ident

ooh

haha

yeah this is too common a problem with remotes

you need to be able to create temporary ident

and then bang it when the real id comes back so that your database is correct

https://github.com/omcljs/om/issues/465