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")
so it returns properly formatted chars.
I guess it's possible to supply my own wrap-transit-params
but wondering if it isn't just good practice to have the writer be UTF-8 in general.Ah, interesting! Thanks for the background info.
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!).
Thank you! Let me check...
It seems you are right, thank you!
@bbss I want to do more testing. This is happening in something like the RAD demo? I’ll have a look.
This looks great @holyjak! Look forward to reading all the way through. Minor nitpick: shouldn't it be ::p/errors
, not ::pc/errors
? (Assuming p
aliases pathom.core
and pc
aliases pathom.connect
, as is usual in the pathom docs.
So, the default in the JVM for that is UTF8, and a system property (file.encoding) controls that default. (See java.nio.charset.Charset.class, line 245). That said, I agree that webapps in general should be using UTF-8, and personally have no problem setting it in this middleware. If someone really wants a different encoding, it is trivial to copy/paste that little bit of code and do so.
I’m guessing you’re getting different because you’re setting something on the platform that the JVM pays attention to.
But I’ll patch FUlcro proper…UTF-8 is my intention
I can reproduce issues…I’ll look into it