Fork me on GitHub
#fulcro
<
2022-04-06
>
norman13:04:12

Is it generally ok to put arbitrary JS objects into the fulcro application state? For example, I'm using IntersectionObserver to test when items enter/leave the the screen and updating fulcro app state, which is used by my page header. (each component in question is creating it's own observer managed by its own component lifecycle). I think it would be more interesting for the header to create the observer with the observed components doing something like (comp/transact! this [(observe-me {:domElement elem)]) to as they mount/unmount. I'm comfortable with the react and JS mechanics here, I just want to make sure I'm not going to be setting myself up for trouble by putting non-clojure stuff (the js/IntersectionObserver instance) in the application state.

Jakub Holý (HolyJak)19:04:46

In general your should not put non-serializable stuff in there, mainly because it might break fulcro inspect. Perhaps just put it in a global atom?

tony.kay00:04:33

Note that Fulcro already indexes react components on-screen. See, for example, class->any. The indexer is also pluggable.

tony.kay00:04:14

Things are indexed by ident and class

tony.kay00:04:59

but yeah, putting js objects into Fulcro state is “ok” but not recommended because it can affect transit’s ability to transfer objects on the wire

tony.kay00:04:08

(including to Inspect).

tony.kay00:04:21

For this particular use-case I’d use hooks instead of component lifecycle, and capture the dom refs in Hook refs (if I understand your use-case correctly)

norman02:04:01

Thanks. I think in plain react I'd use useContext() for this kind of subtree state, which made me wonder if I could use the fulcro app state as the context instead. I'll stick with the implementation I have now since I know that the number of IntersectionObservers I'll end up creating will be small (5 or 6 in most cases) If anyone is curious, I'll report back when/if I do change to a single observer

sheluchin14:04:05

https://clojurians.slack.com/archives/C68M60S4F/p1649189869197999?thread_ts=1649187769.460759&amp;cid=C68M60S4F Could someone explain the -Dtest CLI option Tony is talking about here? I tried to Google for it but didn't really find helpful answers.

Björn Ebbinghaus15:04:10

It is just a configuration for himself. To prevent him accidentally running tests in the wrong REPL.

sheluchin15:04:30

Where can I find documentation for the -D flag? I understand point of what he's doing.. I've polluted my data with accidental test runs a few times, so I'd like to replicate for myself.

Jakub Holý (HolyJak)19:04:33

Our is JVM option to set a system property (here to an empty string)

tony.kay00:04:18

In your Run Configuration in JVM args add -Ddev

tony.kay00:04:37

Or in your REPL (System/setProperty "dev" "")

Benjamin C20:04:58

Are there any example usages of form/save-as-form someone could point me to? I'm not sure I understand how it should be used from server-side mutations. (Or if it is even intended to be used from server-side mutations.) Edit: moved extra details to thread.

Benjamin C21:04:12

Some background: (Also, me thinking out loud to bring clarity to what I am after. 😉 ) I am transitioning a project from plain fulcro to fulcro-rad. Part of the project is on mobile. I want to have what is basically a report on the mobile end, with a report action. I already have a ui rolled out for this, and it looks like reports do not render at all without a ui-plugin installed, which mobile doesn't have yet. I think (if I understand the docs correctly) you cannot simply add a custom render as you would with form/form-defsc. Something that is not clear to me: How do you make a report action with a toggle button? I remember seeing this somewhere but I have not been able to find it again. (rad-demo -> account active?) Can I reuse that functionality from a regular defsc? [status: found ro/row-actions ..] Looks like it just takes a transaction. I'm thinking form/save-as-form is what I am after.

Benjamin C21:04:56

to use that in a server-side mutation: pull current entity from db -> create delta -> form/save-as-form. Is that the right idea, or am I missing something here?

Benjamin C21:04:58

Okay, I finally found the demo mutation I was looking for:

(defmutation set-account-active [env {:account/keys [id active?]}]
     {::pc/params #{:account/id}
      ::pc/output [:account/id]}
     (form/save-form* env {::form/id        id
                           ::form/master-pk :account/id
                           ::form/delta     {[:account/id id] {:account/active? {:before (not active?) :after (boolean active?)}}}}))
Not sure how I missed that before.

✔️ 1