Clojurians Log v2

Is there a helper function for manually querying the normalized app db with a path? For example, what's in [:component/id :current-session :session/account :account/project 2 :project/creator :user/email]? (The session, user, account, and project are all normalized entities)

can you not use get-in for this case?

Then I would have to manually denormalize it wouldn't I? Sorry, I should have specified that sessions, users and projects are normalized entities.

Is there a way for a component to reject a parameterized routing? For example, I have a Project component that has the :route-segment ["projects" :project-id], however, not all :project-id should be accepted. If the received :project-id is not found in the db, or even not in a valid form, I want to be able to reject the request for routing. Is that possible?

More generally, does dynamic routing support multiple components having the same route-segment (but accept different subsets of parameters)?

Reading the source code of dynamic-routing/proposed-new-path, it seems that the target-ident is expected to be an concrete ident. Everything else results an error. Does that mean currently there's no way to do re-direction (without getting an error)? Maybe we could allow a rejection signal or even a redirection signal?

So, you’re talking about a very special case, and yes, if you had a nested router that had already been in state you’re going to have some juggling to do. I’m not sure how to address that in the book any better than the Pre Merge chapter does, esp. around https://book.fulcrologic.com/#Premerge-mutation. I’m open to improvements to the section you’re pointing at, but the example you’re giving is very specific to an unusual composition in your own app.

Yes. normalized-state/get-in-graph

Redirection, IMO, is a global concern, not a component-local one. A “current” target can prevent routing, but an incoming target can only approve it by doing a route-deferred or route-immediate. That said, you could do a route-deferred, and then side-effect and call change route, which will pull the route away from that target and make it stop expecting the deferral to resolve

No. You would implement this yourself by having a component whose job was to accept the overall (most general) pattern and make the sub-routing decision locally.

Update on Fulcro 3.5 work: SHA c10dd2a5a2058bf39391bebc0e9090d0b61cb199 This morning I had a really good idea for how to optimize the new callback-based rendering hooks (for React and non-react rendering). The first draft of this was not doing any optimizations, and as a result did a lot of senseless over-rendering (callbacks). The basic hook mechansim to Fulcro’s back-end is transaction-based, and that fires a potential render every 16ms at optimistic transactions, and network interactions. This means that a single transaction might cause 2+ callbacks on every such root/component/uism usage (e.g. via add-root! , use-root , etc.). The idea I had was a slight modification to db->tree (which is how the tree props are generated from a query). The new version tracks all idents and root keys used, and puts those on the metadata of the props. Then a new function possibly-stale? can use the new state-map and the old props (with that metadata) to do reference compares on the normalized db entries to discover if the props could have possibly changed. In other words props are possibly stale if the entries in the old state map are not identical? to the entries in the new state map, but only at the paths actually used to generate the props. This means that I’m doing the functional equivalent of shouldComponentUpdate, but since it is a normalized database I only need to do reference compares on a very small set of root keys and idents (which is blazingly fast). This will still result in a little over-rendering since I’m not doing actual value comparisons, but in my experience the vast majority of over-rendering happens when you regenerate props for something that has truly not changed at all, and an actual shouldComponentUpdate value comparison is often rather expensive. This will have a huge positive performance impact on these new utilities, probably making them overall faster than stock React-based Fulcro components. The workspaces cards that use these new facilities (composition cards in workspaces) all seem to work with the new changes, but they are trivial enough to not have had performance issues to begin with.

The Fulcro Dev Guide has got a new appendix, "https://book.fulcrologic.com/#_appendix_fulcro_errors_and_warnings_explained", which provides more details for the various warning and error logs you can get in the browser Console. This is work in progress - please 🙏 contribute by adding and improving the descriptions. The intention is that the descriptions should provide more explanation and context than the limited space of the log message permits. And ideally they would also suggest troubleshooting steps. (I am now working on https://github.com/fulcrologic/fulcro/pull/471 to add links to the descriptions to the error messages themselves.)

I’m seeing strange behaviour when using will-enter on a route. I’m using route-immediate and the route-props that are passed to the router are not props but rather the ident passed to route-immediate. Basically the route-props like in this example are not props but an ident https://book.fulcrologic.com/#_controlling_the_route_rendering

And I get an error in the console Props passed to fierce.pyxis.person.tabs/ProfileTab are of the type PersistentVector instead of a map. Perhaps you meant to map the component over the props? But I’m not passing anything, simply returning route-immediate with the ident.

The error is mentioned here https://book.fulcrologic.com/#_components I suspects it’s because the data graph isn’t properly connected.