@sfyire Docs updated for native. See https://github.com/fulcrologic/fulcro-native#using-fulcro-inspect

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.

hm

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?

yeah it has an OO event API - here's a part of it for instance https://microsoft.github.io/monaco-editor/api/interfaces/monaco.editor.istandalonecodeeditor.html

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

yep

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

nice

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

welcome

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

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.

sure

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

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

Appreciate your explanations.

np

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.