Hello, has anyone seen this before?

Uncaught TypeError: Cannot read property 'call' of undefined
    at fulcro$inspect$client$ClientRoot.render (client.cljs:349)
    at finishClassComponent (react-dom.inc.js:13850)

(uploaded screenshots - hopefully they will show)

using these deps:

[com.wsscode/pathom            "2.2.9"]
 [fulcrologic/fulcro           "2.8.0"]
 [fulcrologic/fulcro-inspect "2.2.5" :scope "test" :exclusions [com.wsscode/pathom]]
 [fulcrologic/fulcro-incubator  "0.0.27"]
 [garden                        "1.3.6"]

got it! old dependency was lying around ( https://github.com/fulcro-legacy/fulcro-css )

Moderate me if this is too off topic, but I have a few questions about finite state machines in general. Where can I get a Good Enough(tm) understanding of how to work with them in practice? Are there tools you guys use to draw state machine diagrams such that the UX designer on the team can go "Yeah, that's exactly what I meant"? How do you avoid a combinatorial explosion of state (@tony.kay, I know you looked into State Charts, which tackle this issue, but ultimately left them out of Fulcro).

@d4hines So, Fulcro itself could be viewed as a state machine…one that you organize yourself. Each component has local state, and flows through some set of possible legal states. In a true CS state machine, each of these “states” gets a node, which in turn gives you a really solid diagram, but leads to state explosion. IMO, leaving the diagram “out” for some things makes perfect sense. For example, the states you care about in a form are things like valid?, but form-state already gives you those in a declarative manner, so why duplicate them into a formal state machine? You gain nothing really…all you’re going to do with them is enable/disable buttons, which, again, in a purely functional state component is simply declarative (button {:disabled (fs/valid? props)}), so adding those to a formal state machine is incidental complexity. However, when you have collaboration among a few actors, tracking some extra “state nodes” in a formal diagram is useful (e.g. the state of a user’s session in the context of a login form). With state charts the idea is that you’d implement your entire app with a bunch of state charts…I see that as overkill. Why would I want to mix my state machine related to CRUD on some entity with the state machine for Login/Session? In Fulcro I would not…they can simply be completely separate (and are therefore component clusters…a few UI components and their state machine). The new dynamic router in incubator: It uses a UI state machine in the background…but you don’t (and should not) care. It is an implementation detail that was helpful in specifying how that component works. Interestingly, this hidden use of state machines leads to a routing system that can be directly tied to the URL of the browser for HTML routing which again obviates the need for exposing any kind of formal state machine: the URL IS the “state machine node” you’re in…the only thing you miss is a diagram, which you technically could generate from the possible routes declared on the components. So, in my use of state machines so far I am not seeing any kind of state explosion because Fulcro does not need you to write a big state machine around the entire app. Only around small custers of components. The state machines stay small, and the API stays very simple. Read the paper on state charts and see if you want to really write your Fulcro app that way…I, personally, do not. If someone else does, then they are welcome to contribute a lib 🙂

@tony.kay Good evening 🙂 I’ve a quick question on a problem I just encountered. When running (df/load app :some-key SomeComponent), if there is already something under :some-key in the database, it gets overwritten (instead of merged with) the response to the query?

Because I defined some initial state for a router on my App component, then ran (df/load app :app root/App), but it looks like it overwrites the router’s initial state

options: :marker false

which should be the default…but for legacy reasons it is not

@tony.kay how are markers related to this?

From the doc: > - marker - Boolean to determine if you want a fetch-state marker in your app state. Defaults to true. Add :ui/fetch-state to the target component in order to see this data in your component.

because markers replace the content

aah. ok

thank you 🙂

at least if they are boolean

if you use a marker name, then you get both…old state + marker

what is the reason for the “content replacement” behaviour? as in, is there a specific reason?