certainly looks related to untangled

there’s nothing stopping you from doing what I said in Om Next

@pedroteixeira if you don't care about server side rendering, sablano works fine with om.next

if you use any JS components won't you also need to do node.js based server side rendering anyway ?

does something like this exist for clojure? https://github.com/markfinger/python-react

it just proxies to node "Render servers are typically Node.js processes which sit alongside the python process and respond to network requests."

Does extfs get a chance to customize indexing for :prop->classes?

That appears top be embedded in index-root and not accessible

(I suppose I could just do it during :index-component anyhow…)

Related: Are there any docs anywhere on how the indexer works? What is extfs and what does it stand for?

Possibly a bug (or the lack of a feature): if I have a query like [{:blah/thing [:blah/id]} {:other/stuff {:blah/thing [*]}}] where the second :blah/thing is handled by recursively calling the parser from :other/stuff and assoc’ing :query-root true, such that both :blah/things are the same remote query, only one of the locations of :blah/thing in the client-side app-state is updated. Is this expected? Any advice on how to get both locations of :blah/thing in my client-side state to receive the update (preferably w/o overriding merge, bc SoC). E.g., I’d expect my clientside state to look something like {:blah/thing { … } :other/stuff {:blah/thing { …}}}, possibly normalized (but I think that’s outside the scope of the problem I’m having.

I’d also like providing a read key after a mutation for :blah/thing to update both components using :blah/thing (at their respective paths)

@solussd If you’re trying to get state updates to show up in multiple places in your app state, you would want to use normalization.

You’d have a table in app state, keying like [:blah.thing/by-id <id>].

I think that’s an orthogonal problem. I should have mentioned that :blah/thing is a collection of items and I need the collection to be updated in both places

Normalizing lists is valid [:list-of/blah-things :list-one]

hmm, what’s identity for a list?

Whatever meaning you want to assign it.

For managing users, you could have [:users/list-of :customers], [:users/list-of :admins] etc…

Where app state for those looks like

{:users/list-of {:customers [[:user/by-id <>]...] :admins [[:user/by-id <>]...]}}