The answer is to have a local remote. But my inclination would rather be to not use RAD, use a conventional defsc. Just wondering out loud if it would make sense for a defsc-report to be able to have a :query, as an alternative to a ::report/source-attribute ??

I can see ::report/query-inclusions but don't see how it could be of much help.

there is an override for ::report/machine (undocumented) for coding customizations to how things behave. This is the recommended way to do any behavioral customizations. I plan on adding a global override so you can make it application-wide, but have not yet. This would also answer your other question. Then you’d just derive your own state machine from the supplied one.

ideally, each of my pre-supplied handlers would be in functions that you could easily re-compose into your own. Another option is “hooks” for everything, but that leads to option explosion, and I’d rather avoid that

I can see that ::report/load-report! is called from the UISM. So a new state machine could call its own function that would do a mutation to get the app state as required by RAD reports.

::report/source-attribute could then be ignored. However you would have to put something in there because it is a required attribute.

So that’s true, but a minor issue with an easy workaround.

making a macro’s error checking pluggable is a bit of a nightmare 😜

Overriding the state machine won't help for the other question. That is because the function ::report/report-will-enter is called directly from the macro-generated defsc's `:will-enter`. So, IMHO, a developer being able to put their own :will-enter still stands as a reasonable enhancement request.

Ah, right, it has to return the right value. You’re right…send a PR

user-supplied will-enter is allowed

I’m in the source this morning…I’ll just do it

On 1.0.0-RC2-SNAPSHOT @U0D5RN0S1

Unfortunately taking data from app state rather than using a resolver proved a bit more difficult, and maybe not what RAD is intended for (not yet anyway). Surely all that is required is a change to ::report/load-report! . I tried commenting out the load and doing

(uism/trigger! app (uism/asm-id env) :event/loaded)

remember that RAD report exists because there is a lifecycle around the data, controls, and so on. It is designed to be a full-stack thing, and I had not considered you might do reporting from client-side data.

so yeah, that might require some design work

but I’m not sure why you can’t comprehend it…it’s a pretty small state machine, and the macro outputs a standard defsc. Perhaps you mean the rendering is hard to follow? That I would agree with. Maybe I’ll make another video that goes over some of the internals for customizations.

oh…reports do have stages.

so there’s that: Data gets loaded into one spot, then transformed (optionally) by custom function you supply. Then it gets filtered into a cache, then sorted into another cache, then paginated into the final display rows.

those stages are an optimization for large reports. If you change sort order there is no need to re-run filter, so it can start part-way through the chain

same with pagination: it’s a very fast constant-time subvec of the final display rows…no need to do filter/sort

Can comprehend now. Maybe unfamiliarity with state machines, or needed to sleep on it! Anyway I've commented out everything happening when :state/loading gets :event/loaded , and can see the remote data being loaded into :ui/loaded-data (or :raw-rows). For local population I will try to use BodyItem as the alternative source.

I don't see how a different UISM can help here. ::report/report-will-enter is called directly from the macro-generated defsc's :will-enter.

probably related: this also seems to break the "UI is a pure function of state" guarantee: it seems some duplicate items stay around, while only one of them is represented in the db. am I supposed to explicitly evict the previous route somehow?

React keys?

The items in the list have unique react keys, yeah -- no warnings in console. The duplicated items I see have the same react key (they are the same item after all, in different lists).

maybe this is a misuse of react on my part? I think all I'm asking fulcro to do is flip between two ["view" view-id]s

So, Fulcro schedules a render at transaction boundaries and remote results. Those run on RAF boundaries (16ms). The view is a f(state) is sometimes a disadvantage in that you sometimes end up being able to visually see “transient” steps that you would rather not. Dynamic routing does several steps through transactions, and it may render a child before the props are as you would want them. There is an :after-render option for transact that gives you some control on this; otherwise you have to use things like “ready” flags in state that you use to short-circuit rendering. Other glitches (duplication) are typically react-isms. Fulcro sends the view you construct…but if you misuse React you can get weirdness.

This ended up being a mismatch of versions for datomic-free. deps.edn had 0.9.5697 but I needed 0.9.5703.21 (installed locally).

This has little to do with the query, though it is true that a query cannot walk js objects, the reasoning is more as follows: • Fulcro inspect has to transmit the values…tools are not in the same VM. You put things in the db that are not ok in that, and the tools can break in strange ways. • Communication with the server often includes (even accidentally, where for example you accidentally pass a map that has “too much”) things from the db. If you get things in there that are not serializable, comms will break. • Support: You could technically serialized the db (or a series of them) for use in debugging issues…i.e. as part of an issue report system. Devs could then spin up that real app state history in a dev env from this issue report using the version of sw that the user is running. Putting things in db that are not serializable breaks this. That said, so does component-local state, since it would be missing as well. • Less tangible reasons: “just data” in the database makes things easy to read/look at/manipulate. You can easily convert clj to js data in render if necessary, and it is “fast enough”. Mixing stuff in db that is not clj data leads to convoluted code.

So, as a best practice I put serializable data in the db. If I really really need speed, I consider component-local state…but only really as an optimization when it is proven to be too slow otherwise.

I don't understand. You want to take the current props and just replace the ID prop with a new value? And you don't know how to find out what is the ID property? I think :ident whatever will be replaced with a fn of props -> ID value so you can't get the prop key from it.

I'm basically trying to clone a component given props in the db and the component that renders it

To make a copy I need to replace the id

And the problem is...?

I don't know the id keyword beforehand

(comp/get-ident Class props)

What @U09MR0T5Y said. Even if you send empty props you’ll get back an ident whose first element is the keyword you need.

The magic of the macro turns :ident into a lambda if it isn’t.

Oh, duh...... Should have thought of that