Clojurians Log v2

I've been diving into statecharts recently, and I'm currently using them with React Native in a project. It's been quite interesting so far! But to be honest, I'm not very familiar with those yet. I'm still trying to wrap my head around some concepts. I'm wondering if there are any areas where I could potentially contribute or get more involved with your work on the statecharts integration, perhaps through bug fixing or other tasks. I'd be happy to lend a hand and learn more in the process. Any thoughts on where I might be able to jump in?

copy from @tony.kay First read what I just wrote there 🙂 I can push my current refactorings on a branch for you to look at. They are not ready to release I don’t think, but I’m working on the modal case at the moment, which I didn’t want (in my case) to be an rstate, so I wanted the entry code for doing the dyn query/initialization factored out, which is what I’m doing branch is refactor-rad-integration-apis been a bit since I worked on it, so don’t know if it even compiles ATM to be honest but if you look at the latest commit you’ll see that I’m making some of the ops into mutations so that they appear in Fulcro Inspect better, and trying to make the general operations that the statechart stuff uses into general-purpose functions. I should probably move these into different utility namespaces, or perhaps into Fulcro itself. Dynamic query manipulation for these purposes is actually quite generally useful. Once you understand the basic design ideas, then I’d be glad to have help playing with cleaning it all up into nice APIs in the proper place(s)

copy from @tony.kay I’m also analyzing how we might make things a bit better in the “glue” department. Right now you have to declare the state, name which component is the UI element for it, and then the UI element needs to remember to route the one (or many) children that correspond to the one or many (in a parallel parent) UI elements. I think this all works out ok, but since it requires you to slap it all together it does have some elements of logical duplication, where refactoring then becomes more of a challenge. So one of the nice things about dynamic routing was that there was only ONE place to say everything. Routers listed targets (and rendered them) and the targets had the locallized route details (segment, etc). That made refactoring pretty nice: Just move stuff around and the routing tree self-heals. When the statechart bits if you move a state, you also have to pay attention to manually healing the UI graph. I don’t think there’s any way around this, other than to co-locate the sub-section of the statechart ON the component itself (which we could do), and then somehow generate the overall statechart by automatic composition. So, that’s still on my mind. It might also be nice for me to dupe this convo to #fulcro so others could chime in 😄

I've built a modal chart using statecharts. It's kinda similar to routes in some ways, but also different. The thing is, it's super tied to the UI right now. I'm gonna compare what I've got with the latest branch and see if I can loosen things up a bit and then make a pull request.

Ok, thanks. I'm pretty busy lately, so thanks for the help

One the modal thing: I haven’t put anything in public code, but since the new composition in statecharts leverages a special state to represent a route (and track optionally in the URL), there is some additional composition (e.g. a statechart embedded in a component) where you might want states to control the VIEW, but NOT the URL (e.g. a modal appearing). This is kind of “ui routing” but isn’t a global concern (URL)…it’s a local one. That’s the reason I’m trying to factor out that code from rstate : so that it can be used to make modals that still edit a parent query and initialize some sub-graph, without affecting the URL or other global concerns.

I've been working on decoupling modals from the UI and comparing the differences between routes and modals over the past few days. Here’s what I’ve identified so far: 1. It doesn’t automatically enter the default child modal, meaning all child modals can remain in a closed state. 2. Automatic close behavior: when a ::close event is triggered, it automatically returns to the parent modal or the default initial state. 3. [To-do] Update the state of the component associated with the modal. The API is currently designed with these methods: (open! comp modal-key), (close! comp), and (close-all! comp). Does this approach seem reasonable to you? Are there any mistakes or potential oversights I should consider?

Following this thread. @openefit are you using rad in your react native app?

@yaw556 Yes, I am actually using Expo, React Native with rad in my project.

I basically just decided it was better to directly write the objects to S3 from the client so I didn't have to upload them through my server at all. That offloads a bunch of network traffic from my servers, at the expense of occasionally writing trash. But by using the file Sha as the S3 object name it ensures that I never have duplicates. This means that if the user is having trouble saving the form or something and they reupload some large object, I can avoid it altogether. So basically I made a resolver to get a signed URL for S3 upload, and that resolver just returns a status code when the object exists. If you want to get the Temp storage working, you kind of have to deal with a bunch of other issues. What happens if you have 10 nodes running for scalability? Well now you have to have something like NFS to share your Temp storage or your upload is only visible to one of those redundant nodes. For me, it was just much better to let the user use a signed URL to upload straight to S3, then front that with a CDN

So, for my production purposes, it turned out to never make sense to bother with the Temp storage

I see. Sounds like you may have a custom file upload UI to a mutation. We were able to write a custom BlogStorage called S3BlogStorage protocol. It works with the default RAD file upload UI controls.

Yeah, I ended up making a custom control that does what I said: User clicks upload, calcs SHA in js, sends a request to server to get s3 signed URL for direct upload (OR a “already have it”). So, the only thing that gets saved to the server is the SHA and file details like filename. No upload data flows through my server at all, and the CDN prevents download from coming from the server as well.