Fork me on GitHub

@foobar component tree: Yes, afaik a component tree exists and it is a tree. unique ident: I don’t think it’s this simple, as there exists the possibility that more than one component is used to display information about the same logical entity. i.e. You can have two components with the same “ident”. updating state: What I’m used to and what I’m assuming the common case is, is for us to know in advance what the child components want. And if there could be many different classes of child components that have different needs, then we can expect them to be a bounded number of classes, and we would still be able to know in advance what the children want. So it seems you’re trying to do something vastly different from this, and I think it would help if you gave a concrete example of what you’re trying to do.


can someone show me example of a component that “propagates” a custom event to the parent component?


I I just pass a prop that a function and just call that function at some point from the body of the child component, is that ok?


@ag didn’t quite understand, are you suggesting passing a function as a prop?


and also, as always, why not simply transact! the global state? if you really need “event passing”, I would pass a channel from the parent to the child, and have the child put! messages onto the channel and have a (go (loop … ) ) in the parent that takes values from the channel and does something with them… but that can easily get messy and create a lot of dependency between components, so I would really think if you need it or if there’s a better way


ag: yeah you can pass a function to a child, just do it thru a computed


I'm trying to remove some keys from a query before sending to the backend (ui namespaced). It isn't normalizing the response anymore with the default merge. What cue is using to know that the response should be normalized? Is is comparing the query to the component with the ident and it can't normalize because I modified the query somehow?


@danielstockton it’s in the meta of the query, check if you still retain that


Ah right @alex-glv, that's almost certainly it.


@levitanong Yes I know in advance what the components want. The information is transacted into the state. What I cannot update is the query for the component that hosts a newly added component. I obtain the html contents of a host component dynamically. I am then using prewalk to convert a html element into a component based on its attributes. An example would be an input element that specifies its data-source. My pre-walk would then instantiate an auto suggest component in place of the plain input element. What I cannot change (at least when using datascript as the state) is the host component query.


@foobar Let me get this straight. You have some component, AutoSuggestComponent, which, as a user types, will call some method from, let’s say... google’s places autosuggest, which does some remote query and returns some premade markup containing the results. This markup is placed into app state as a string, which you parse and use in the render method of your AutoSuggestComponent. Is this correct?


Creating such a component is fine, creating it dynamically when required is not


The auto suggest component could be any kind of component, that was just an example.


I’m not sure why you would need to update AutoSuggestComponent’s query though.


I don't I need to update the query of the component that is hosting the new auto-suggest component.


so like, some component AppRoot


and you have AutoSuggestComponent


why would you need to update AppRoot’s query?


So AppRoot would get its contents from some dynamic source. I want to render some of the contents as components.


Therefore I need the query of AppRoot to change, obtain the required information, so it is available to be passed to the new components hosted by app root


and i suppose dangerouslySetInnerHTML is unpalatable to you? lol


Well om next offers me all of the machinery to make a dynamic component just work, if only I could update the query of its host to fetch some additional information


I’m curious, why would you use something that gave you markup though? Is there no alternative that just returns data?


Its more intuitive to describe a fragment of ui using markup. In this case an input element clearly communicates its purpose and is even functional by itself. The fact that I can add a couple of attributes and dynamically suggest values to the user is a nice to have.


My requirement is that my ui fragments are the bare minimum so I can create them by hand.


I want to create and render a new ui fragment, rather than re-compile my entire application.


@foobar your needs are valid and i hear you on that. there may very well be a nice way to do this in om, but as far as i know it will be less effort on your part if you create an overarching UI piece that has all the other possible UI components included or mapped in. I have one gigantic (monadic?) component at the end of my UI code that basically gets each individual components' query and also maps the results to their UI code. I don't update any parent queries or anything like that, I just make one "super parent" at the end that says "i want this query and this one and this one" and, reiterating, it just maps to the extant ui components. i could share some example code if you like.


For om SSR, how can I get the initial state on the server? I can render to a string just fine now, and it gets rendered on the client. However the client has no state yet, so falls back to default values - and then updates again. I would like to pass the initial state to the client (maybe in a div), but how can I get it on the server?


In a read, is reading the (:query-root env) the correct way to detect whether you're reading an ident or a simple key?


I don't see the ident anywhere else. Am I missing something?


I would see if (-> env :ast :key) is an ident


Oh, in the ast


Fair enough. Is it typical to dig into the ast for that?


IIRC, the ident will only be in query-root if you’re using path optimization


That makes sense