A quick note on the new sync tx processing: I said this before, but do expect that it is mainly directed at testing at this point, and should be considered alpha. I don’t recommend switching to it in production, but please try it in dev and report issues. I’d love for this to become the de-facto transaction processing, but I have not had time to vet it heavily. It has worked in my limited testing but I have already seen minor visible differences that will matter, and might require adjustments.

has anyone dealt with a stale client? I'm not sure why it decided to start doing this. I've tried restarting everything.

oh this might be shadow-cljs, I'll ask them

@tony.kay I notice the new sync tx processing is different, it appears faster, in a fast sequence of actions it shows a label that wasn't really visible before. However it seems the :event/saved doesn't get called unless I run another action, this is with the rad form machine so probably from uism/trigger-remote-mutation not functioning properly? It's a bit hard to tell what's going on now the log output is a bit lighter.

Could be I need to trigger one more render in some cases

But you're saying an event is just missed? That should not be

I'm not sure if I am doing something wrong with uism use in general. I'm currently running into issues I can't explain with state-machines, not related to this sync tx. Had similar things a couple months back, thought I fixed my understanding now but sometimes still seeing some odd stuff, might be my mistake though. I'm not sure where to begin! my state-machines. A natural place to start many of them would be in an event handler of a different state-machine, but that gets called on the app and not the this/env. I'm afraid that might be tripping up the event queue or something?

different topic: maybe the default api-middleware writer could be UTF-8? Since I deal with Korean text a lot I have this line https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/server/api_middleware.clj#L152" changed to

ret  (.toString baos "UTF-8")

Hey, I have started to use the hook support. When I add :use-hooks true to my Root component the initial-state is merged into the DB each time I change code and shadow-cljs refreshes. Should a Root component use hooks?

Is there some tool somewhere to provide time travel without relying on Inspect? That is, without resorting to ser/de. I find it gradually harder and harder to work like that, too much restrictions (no sorted collections, no fn when it would really make sense, and so one)

Can computed props not be used as part of an ident?

Are there any best practices around deriving ident values from parents of nested entities/components? I'm using the form state machinery and the components need :idents defined, but some of the forms are editing nested data that doesn't have an identity, e.g. the address in a user entity {:user/id 123 :user/address {:address/city ...}}

In this case, the user/id would suffice as part of an identity like [:address/id 123]

@mroerni I don’t think your problem is hooks. I suspect you’ve configured shadow to call the wrong startup function and are recreating your app every time, or forgot to use defone, etc.

@adam678 so, there’s >tap in shadow-cljs, which is nice, but serial. The other option is to add a hook of your own where you could track your own history in an atom, then just use the repl to look at it. You could put that in a render-listener (app config option), plug it in at submit-transaction! (another app option), etc.

The new db explorer tab in Inspect was built to address some of those isses. The db tab itself is hard to nav since it renders everything…

@solussd correct. computed is for rendering, not for state. A component could be used in diff contexts (parents). The answer you’re looking for: You have to pre-populate the state before you try to render it. RAD uses UISM to do the control steps including creating “templates” of new children. You could have a look at that. dyn. Routing’s will-enter is a decent place to start if you’re getting there via a route.

but pre-merge is good if you’re pulling one thing from the net and wanting another to be initialized….though I generally recommend using UISM these days for forms…there’s just a lot going on…and I’ve already written than generalized SM for you…it’s in RAD 🙂

Cool, thanks!

No more weirdness on my uisms, figured out my problems. But do still have the issue I mentioned when trying the stx/sync-tx! after going to :state/saving there's no progress until I try to go back and cancel (which it can't because I don't have a cancel event for :state/saving ). So it does sound like something like "need to trigger one more render"?

I have finally finished my "Error handling in Fulcro: 3 approaches". Thanks to Tony for his invaluable criticism and advice (and for Fulcro!).

@bbss I want to do more testing. This is happening in something like the RAD demo? I’ll have a look.

I can reproduce issues…I’ll look into it