Fork me on GitHub

I’ve added a signup uism to the RAD demo. Once the registering is successful I want to trigger the login flow, without the user having to re-enter their email and password. The LoginForm from RAD transacts the login mutation which remotely checks the credentials and locally in the ok-action checks the status and calls in the RAD auth system for either a success (auth/logged-in) or a failure (auth/failed). I’m not sure what the best approach is here. One idea I had was to have auth/Session as an actor in my uism and replicate the login mutation with a trigger-remote-mutation. Any other ideas for a better approach?


The auth thing in RAD is half-baked. Just write something new. Copy the state machine out of what is there and add some more states and events to it.


Ok. Thanks. I have a half-baked solution on the half-baked RAD implementation. I feel half-baked myself after working through this.

😅 2

Is there an elegant approach to triggering a change of route from a uism? The examples I’ve seen require app and call dr/change-route directly from a handler.


write a function like this:

(defn change-route-relative [{::uism/keys [app] :as env} router-actor new-route]
  #?(:cljs (dr/change-route-relative app
             (uism/actor-class env router-actor) new-route))
and make your router an actor

holyjak08:12:45 is now live. Many thanks to everyone who contributed! ❤️

🎉 3

Are diff added / diff removed broken on the new versions of inspect? I'm seeing nil everywhere, but it could just be my stuff being stupid.


Tony would accept a PR fixing it but I personally do not have time to look into it 😞

👍 1

Ok. I may try to get the project spun up and work on fixing that if someone else isn't doing that already

🙏 1

There seems to be a 2nd regression as well - looks like the db tab is treating state as (seq {state stuff}) and goofing up when you click an index to add to watches


Scratch that last note --- not sure what happened, but that particular issue was just a fluke


well, look at that, the entire issues fits here…so, reading it is even easier


My apologies to the the person that opened the issue. I realize this might be a little embarrassing. I have no personal hard feelings toward you at all. I just have a need for people to be a bit more enlightened. Forgive me for using your issue as a “teaching moment”

Björn Ebbinghaus20:12:49

FYI: There is even a hooks helper namespace: com.fulcrologic.fulcro.react.hooks


yup, although for useCallback we actually have access to that "sufficiently advanced compiler" the react docs mention and properly express its intent


it’s also worth noting that if you use timbre, you already have encore, and encore has a memoize that will GC and can have a TTL. It’s a much easier thing to use that gets you 95% there with no need to even “name” your dependencies.


dang. and I went to the trouble of making my own...


yeah, I think everyone should look through encore…there’s a lot of useful stuff in there


does anyone have a strong opinion about whether keywords used for data (so, ones appearing in the fulcro db or in pathom resolvers/mutations) ought to have "full" namespaces? in general clojurians tend to prefer "full" namespaces like :com.mycompany.widget/id , but it's common at least historically for fulcro projects to use :widget/id. Personally while I'm sympathetic to the best practice of using full NSes in general, a major reason for this practice is to avoid name clashes, and if your app is never going to be a dependency for another system, and data flowing into your app won't clash with abbreviated namespaces, then I wonder whether abbreviated namespaces might be harmless and perhaps even preferable for certain kinds of readability


i agree with your assessment


non-library applications should use :widget/id, readability is very important

👍 2

I concur; with one caveat: If you expect your data store to be published for use in federated data system (i.e. you might pair up with other companies and use pathom to combine data sets in a federated graph) then it is quite useful and important to use the longer names. Most people are just building some in-house thing that doesn’t need to integrate that way, so the shorter name does create less mental overhead/work/aliasing

👍 1

right, that's uncommon in my corner of the world but i'd expect it to be perfectly normal elsewhere... one way of having your short namespace and eating it too could be to map between short and full namespaces at the system boundaries (`:com.mycompany.widget/...` <--> :widget/...) but now you've got a mapping to maintain and the responsibility to make sure it's applied just where it's needed


yep…aliasing a lot of stuff creates way more headaches than having to type a little more during dev