Fork me on GitHub
#fulcro
<
2019-02-01
>
nha17:02:50

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)

nha17:02:50

(uploaded screenshots - hopefully they will show)

nha17:02:46

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"]

nha18:02:17

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

Daniel Hines20:02:08

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).

tony.kay20:02:42

@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 🙂

Daniel Hines20:02:31

This is a really great insight into Fulcro as a system (one I'll have to chew on 🤔 ), but my question was more around those component-local state machines. I'm confident that I can implement state machines quite easily (like you said, Fulcro makes that really declarative). My present interest is in using the language of FSM as a communication tool to iron out complex behaviors in apps. Do you have any tips or tools to that end?

tony.kay22:02:44

Incubator’s UI state machines. The declarative nature of those is meant to be quite amenable to tools

tony.kay22:02:04

and that is where you’d handle your “complex behaviors”

tony.kay22:02:27

and they can talk to each other…so you can have some top-level FSM that directs actions of others if you want

hmaurer23:02:19

@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?

hmaurer23:02:59

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

tony.kay23:02:55

options: :marker false

tony.kay23:02:14

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

hmaurer23:02:28

@tony.kay how are markers related to this?

hmaurer23:02:42

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.

tony.kay23:02:55

because markers replace the content

hmaurer23:02:10

thank you 🙂

tony.kay23:02:13

at least if they are boolean

tony.kay23:02:22

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

hmaurer23:02:09

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

thosmos01:02:35

I like to use it to put a spinner or "loading ..." note at the place of the content