Fork me on GitHub

Fulcro 3.0.17 on clojars, which supports setting the option you need


Is it an anti-pattern to have dummy/shim components to use to watch/query for changes in the app DB? In other frameworks I've used things that amount to watches on atoms, but doing that directly on the state atom feels wrong in Fulcro. I can explain further but it's a bit of a wall of text. Generally what I'm trying to do is sync a complex state graph in the app DB with a 3rd party JS only component that can only be directly wrapped by a single Fulcro component.


@twicebaked The standard pattern for dealing with adding data that will refresh things is to use merge-component! and let Fulcro figure it out from there. So if you mean “is it ok for a component to have a query on data it passes to some child that is js?“, yes.


“watch” isn’t the term I’d use, since that brings up connotations of atoms and event systems and such


well by watch I did mean the state atom


Perhaps a concrete example will help more


no, that is what the component queries are for: to ask for what they need out of the db


then they will re-render and can refresh children…which is the wrapping I think you meant


The actual problem is this - the 3rd party component is a JS-only editor with a very large API. The editor renders a lot of UI and buries its own state internally. The actual API can only be called after it attaches itself to the DOM, meaning only after my Fulcro component attaches it in componentDidMount . What I'd like to do for instance is to make a change to some data related to the editor and have it call the editor's API.


A good example would be I have some metadata that is used to calculate text decorations. The only way to visually update the editor is through its API. When the source data gets changed in the APP DB, I want it to automatically call the editor's API.


The wrapping Fulcro editor component itself just queries an "editor" table at the top-level with some relevant state. Updating that stuff is easy, ex: via shouldComponentUpdate. Where it becomes more annoying is when the state I need is a few relationships away, but there's no real on-screen representation other than in the editor itself (visually, and the state itself is hidden away in its internal OO state).


Right now I'm using mostly a combination of the editor's event hooks, pre-merge, react lifecycle methods, mutations, and post-mutations (on load) to manage the mess. The wrapping component though is turning into a bit of a monster so my hope was to perhaps farm out managing some of the state changes somehow.


The answer might be there's no way around it 😄


so, any time something manages DOM of its own you’re in a shouldComponentUpdate/componentDidUpdate sort of situation


yeah that's what I am doing now and it works, but it's certainly a pain when dealing with things that aren't for instance in the editor table itself


so, your problem is this editor has something you need…what are you thinking you could do there?


I mean, does it have an OO event API or something?


So far everything I am doing works, my goal is to really simplify


I think it is an anti-pattern to link to anything that says microsoft…


it feels like I just have this giant mess hidden by functions


I'd gladly change if not for a few reasons 1. out of my control 2. It at least has an underlying buffer that isn't just some ugly line array that ends up crapping itself when the content grows or for certain hot ops 3. Wide community support at least


“Where it becomes more annoying is when the state I need is a few relationships away”…you mean in app db? You are aware of link queries, right?


yeah I'm aware of link queries


even on my side, the state I need to sync with it can get pretty deep, especially because there's no way around some of the design of the editor itself, ex: some things need to be done to the editor, some to the underlying buffer (also a specialized object)


So, you’re certainly allowed to watch Fulcro’s state atom. The query system is there to make that less obnoxious and to handle efficient refresh. If you watch the state atom and do side-effecting sorts of things into you js component, that is fine. Not going to hurt Fulcro


Yeah that's where I thought what if I did something stupid like create components that query some of these other tables and make the API calls in shouldComponentUpdate for example


then I could at least group them in some component that includes the editor and all these other supporting components that don't really have an on-screen representation themselves


Yes, there’s no getting around some of that kind of ugliness when the thing you are working with requires it


OK that's good to know at least there isn't some kind of other pattern or feature I missed that would simplify things


I’d prefer a clear normalized data model in app state as a control, and the lifecycle methods as the (hidden) ugliness that makes it work


no watch on atom


yeah hence the components instead of a watch


For example, I’ve written a 3d app that uses three.js…Fulcro does very little in the wrapper, and actually hooks up a separate 3d reconciler for the internal state of three


but it reconciles my normalized objects from app state into the mutable objects in three


in that case I’m asking for the entire table [:object/id '_] in my query


and passing that table to my 3d reconciler


that way Fulcro’s overhead is minimized (doesn’t have to do denormalization on the objects, which are self-contained anyway)


OK that makes sense, so one query grabs the entire state tree and that deals with it elsewhere


and you leverage just enough normalization in Fulcro to get sanity in your data


I do have a good amount of state that is read/generated elsewhere so that part needs to still be normalized by Fulcro probably


and that’s where you can choose to use components that themselves do no render, but are used in query of components for data merge story


for the load part I do that already


Components that correspond to normalized data must be represented in the query tree of the UI components, but the UI components only have to use them for rendering if they care about targeted refresh of the children


if I had the time I'd just write my own editor in Fulcro


that’s always the trouble 🙂


comparing some of the things I'm doing to similar code in vscode, it's already ridiculous how much they overcomplicate it and how simple those things look in fulcro


it’s best to leverage community stuff for things like this


but yes, I have been working on Fulcro for 3 years and it still surprises me how much it cleans things up 😉


I wrote an initial prototype of this project in typescript


I wanted to die because the whole time I just wanted an app db


convinced them to let me do some things in Fulcro since it simplified everything else


I swear it's orders of magnitude less code which is not shocking at all


anyway thanks for the input, I'll let you get back to it. Much appreciated.


3.0.18 on clojars. Fixes a regression in inspect reporting (UISM is not showing events, but instead the low-level mutation call)

👍 8

Are Fulcro state machines hierarchical?


Or can they be?


not really. My intention was to get something working with the amount of time I had to implement it. I read Harel’s paper on state charts, and decided that was more than I wanted to tackle, esp since I could get what I wanted from simple FSM. After using them I realized that Fulcro already gives you normalized state, where you can track/have any number of state machines. This gives you the essentials to get “history” when you re-enter (i.e. show the UI for) a given machine. They can send events to each other, so that gives you general communication.


heirarchy can easily be structured from this by simply passing the IDs of state machines to each other


> They can send events to each other Like actors?


in fact, that whole mess can be dynamic, which i’m leveraging in RAD: the master controller is sent IDs of state machines it will communicate to


careful with terminology…I unfortunately overloaded the concept of actors in UISM in Fulcro


but yes, similar to actors in dist system terms


Okay, thanks. So it sounds like it’s possible through means of IDs


in UISM, an actor is a UI actor…a component filling a role, so you can swap out UI instances on a running state machine, or re-use logic with diff UI impl


it actually turned out to be super flexible…yes, I think you’ll be able to get what you want, though with slightly different approaches. The down-side is I’ve not thought through the full semantics of things like Harel did…so the model is not as theoretically sound.


but it is working very well for me 🙂


I see. Alright. I’m still a Fulcro noob, so for all I know statecharts are not needed.


Just saw that going around in the JS world with XState and wondered if that were the implementation here


no, xstate is true state charts


UISM is FSM tightly integrated with Fulcro primitives, and because there is a state db already you end up with some of the things statecharts is giving you. By putting the state machines in Fulcro’s app db you end up with interesting additions to FSM that mimic the abilities you get with S.C. You have “instances”, can have more than one (with known ID), can communicate between them (triggering events across machines)….that latter bit is what ends up giving you a lot of the xstate stuff…it just isn’t hierarchical…so you lose something there.


the “outer” vs “inner” scope isn’t implemented for you…though if you want that, you can technically have the “inner” one read the details of the “outer” one using the state map and the outer one’s ID.


it’s a global normalized db


Okay, makes sense. Thanks.


Is UISM pluggable? Could one write an SC implementation and replace the current one?


no need for it to be…I’d suggest just a separate ns that implements it…there is zero coupling


you could probably wrap the current API with another and get it…but I’d suggest you implement some things first to see if you actually notice a failing that inspires the extra work


so far, I have not


The holy grail 🍷


zero coupling ^


well…it’s unidirectional…UISM does have to understand how Fulcro normalizes things


but Fulcro has zero knowledge of UISM


it was originally in the incubator library as an optional extension, but was so useful in our projects that I made it official ns in F3

👍 4

Nice, well I’ll give UISM a try before writing anything


Appreciate your explanations.


Warning: Fulcro 3.0.14+ will break custom http network middleware. In fact, there is no way for me to fix the thing that was broken without an incompatible change at that layer. It was an oversight in much earlier design phases (pre-3.0). I’m going to bump to 3.1.0 shortly, which really should have been done at 3.0.14. Sorry about that. I’ll document the fix in the middleware docs of the devel guide when I get it done.


I’ve released 3.1.0 to clojars. This should not be a breaking change for most people, but the interface at the http-remote client response middleware had to change slightly. The response map no longer contains a :transaction key from the raw http remote, it instead contains and :original-transaction. Middlware that wants to rewrite the transaction MUST return :transaction in the responss still, and therefore response middleware should check for both keys.