What you’re looking for is a link query: http://book.fulcrologic.com/fulcro3/#_link_queries

Right, but the current user is kind of a global, root-level thing. Can I arbitrarily query root-level things in in subcomponents?

(The app does rerender on login/logout already, but the shared-state updates seems to lag somewhat behind that re-render)

You can have keys that are right at the root of app state, and query for them from any component. Especially useful for things like the 'current user'. See http://book.fulcrologic.com/fulcro3/#_link_queries.

Thanks, I’ve read the documentation back to front, but managed to skip over that one somehow.

I would recommend link queries over shared. Shared has been around since the beginning, but was never my favorite feature…but removing it is impossible since ppl have come to rely on it. There is also, of course, react context, top-level atoms, etc. Lots of ways to accomplish similar goals, but link queries participate in the rendering refresh story, so they are more reliable.

I will throw it out with haste!

I sat down with the UI state machine video and converted the session code, and that cleared quite a few things up. And right at the end, you briefly demonstrate the '_ syntax as well, which would have answered my question if I hadn’t gone ahead of myself.

Given the global nature of session stuff, I guess this is OK for this particular use case.

yes

same with things like i18n locale

you want a full refresh

Of course not

Nevermind i found it, its the optimized-render! key in a fulcro app

`:optimized-render!` - A function that can analyze the state of the application and optimally refresh the screen.
     Defaults to `ident-optimized-render/render!`, but can also be set to `keyframe-render/render!`.  Further customizations are
     also possible.  Most applications will likely be best with the default (which analyzes changes by ident and targets
     refreshes), but applications with a lot of on-screen components may find the keyframe renderer to be faster. Both
     get added benefits from Fulcro's default `shouldComponentUpdate`, which will prevent rendering when there are no real
     changes.

Keyframe-render is all I want in life

I’ve found the ident renderer quite accommodating so far.

I spent a lot of time making the ident-based optimizations good, but they do still require you to indicate refresh on dependent data (parent looks into children to render things like summaries)…the keyframe makes everything magically automatic, but it does sacrifice a bit of performance. That said, keyframe on most desktop computers will be fast enough…mobile is where you might reconsider. Even then, using React-style optimizations (use component-local state to do form input control) is usually about all it takes to make it all irrelevant, if somewhat more buggy and complex 😜

I was rewriting from fulcro 2 to 3 and realised how many follow-on-reads we used in txes.

Yes, but it doesn’t necessarily know which B or A it belongs to unless I give it that information, does it?

I.e., B knows which Cs it owns, but a C doesn’t know anything about the calling B necessarily.

You can check if particular ident is in a to-many.

or a to-one.

Right, filter on all Bs, then filter on all As.

Yes, the layout of your screen should be there in the app state.

But you still might want to pass helpful things down as you say.

And for component to component communication (as I call it) you use computed.

Yeah, it wouldn’t help with dragging and dropping a C from one B to another I think, since the mutation doesn’t happen until after the drop, at which point it needs to know both the target and source B to move the C.

So id of A being passed to B and of B to C might make sense. But none of this should be essential, as your app state tells the whole story.

No, hang on. You’re right, the source can still be derived from the app state, and the target is implicit in where it is dropped.

Thanks for the advice, I’ve gone a bit overboard with the computed in the implementation. I think I’m going to see how much I can derive from the app state and confine to the mutations.

Yes, you have the luxury of two events if you are talking drag and drop, so two mutations, so chance to put anything helpful you might need into state as well.

Yes - becomes all about mutations, and st->st* functions they call...