Fork me on GitHub

@tony.kay HTML5 routing is definitely broken. I can reproduce it with an unaltered Fulcro RAD Demo. E.g. browsing to http://localhost:3000/invoice/edit/edc5b104-5937-4d6c-a96d-da43a1359bf4 will fail, despite that being the URL that gets generated for the edit form.


did you restart the app? UUIDs change all the time


I definitely use it in production, and have not seen a problem 😉


but that UUID in your URL is a generated one, and if you’ve restarted the server, it won’t be there anymore


so i use a db that can stream entity id's that have changed and i'm thinking about how to use it to implement live updates. assuming i broadcast these to clients on a websocket connection, i think all i have to do is keep a table that maps entity id types to a component (e.g. {:user/id UserComponent}) so i can (1) look up the changed id in the client db and (2) load! it against its mapped component, right?


@tony.kay Nope, no app restart. npx shadow-cljs watch main, evaluated the development ns, ran start and opened the browser. Logged in, selected an invoice, then took the URL without the ?... stuff and opened it in a new browser tab. It fails to load and replaces edit and the UUID in the address bar with keywords.


well, the ? stuff is significant, so I can’t say I’ve tested it without it. If you were bookmarking you would not remove that, you’d just bookmark it


Yes, so it does not work without the ? stuff, unlike "normal" path segments like http://localhost:3000/invoices which do still work with it removed (it just gets re-added on load), so it feels inconsistent


ok, I would agree that it is reasonable for the user to expect query params to be optional. That said, I don’t see a major problem for 99.9% of real users, and internal routing is not a problem either. So this is a pedantic issue that I have no time for. Perfectly willing to take a PR. Clearly something I’ve encoded into that param is expected, and there’s probably just an if needed somewhere to check for it.


@lgessler right, except you already have the data, so it isn’t a load, it’s a merge…see merge ns merge-component and merge-component!


and there should be no need to do (1): look up the changed ID, unless you have extra actions to do besides merge the data


well, for that matter, you’ll know the changed ID: it’ll be in the pushed data…oh, you’re just sending the IDs…well then, yes, I guess you could load, but why not just push the changes and merge them?


hm... to know the changes, wouldn't i (to do it perfectly) need to keep track of the last thing the server told each client?


if you're suggesting pushing a diff


(defmutation fsa-upload [_]
  (action [{:keys [app]}]
     (dr/change-route! app ["main" "fsa_report"]))
  (remote [env] true))
This is a mutation that I have, where I want to reroute after an action is completed. Now ideally I would like to use the component names instead of the strings mainand fsa_report . However that will introduce a circular dependency, as the mutation ns is used by the target components. What is a good way to deal with this ?


You can use registry-key->class from com.fulcrologic.fulcro.components for the circular dependency problem of needing to depend on a defsc component.


@U0D5RN0S1 thanks, had forgotten about it !


In our meeting yesterday we were talking about the fact that Fulcro never “auto loads” things, and @hmaurer said this, which I thought I’d share: > When I first discovered Fulcro I had similar feelings about Fulcro being “unclear” as to where data-loading should happen. Especially coming from GraphQL and libraries like Apollo/Relay, I was expecting Fulcro to load the data automatically on mount. I took me way too long to realise that Fulcro’s approach is actually really good. The JavaScript ecosystem also seems to be wisening up to it. For example Dan Abramov (react core team member) recently said that he thought useEffect was overused, or misused, for data-loading. Data loading should happen in response to user events, not in response to component renders. As a historical note: I originally planned on writing a server subscription system that would do auto-loads and keep data up-to-date…then realized that that approach is a subset of general functionality. What Fulcro has is what I consider the general functionality: The ability to demand data when needed, and merge it “if it arrives” (e.g. through some websocket push system, etc). I’m glad I realized that myself, but hadn’t realized that others would be assuming (from external lib influence) that that’s how it works.

metal 6
👍 6

I'm trying to use a :global-eql-transform to dissoc lambdas (which can't be encoded by transit by default) but it's not working because transit encoding happens before :global-eql-transform is invoked... does anyone have any suggestions for a workaround?


@lgessler you should not have lambdas in your txes ever to begin with


but I would have thought GEQLT would be in there before…you sure your code is right?


tx processing does apply GEQLT before network layer


There are a few ways to deal with wanting lambda-like things in transactions: 1. make the lambda-like thing be mutations themselves…mutations are data, so you can include them in parameters without harm. 2. Use a custom dispatch mechanism and pass the data around what you want to invoke that way. 3. Pass the function in the transaction options map, which is visible in env in the mutation.

👍 3

(1) and (3) are the ways I usually do it


ooh, didn't know about (3), that will work great. thanks!


I’m not sure that (3) is true within ok/error action, FYI…you’ll have to try and see (if you need that)