I am not sure if I understand you correctly. You want a switch, to toggle if a mutation goes remote or not?

The mutation is only going remote if the body of remote (or any other remote with a different name) returns a truthy value. So you could write:

clojure
(defmutation my-mutation [:keys {remote?}]
  (action [env] …your client stuff…)
   (remote [env] remote?))

Forgot, that Slack still can’t to highlighting

Ah neat, thanks!

the best person to ask would probably be @U5P29DSUS, i believe he has a lot of re-frame experience

@U066U8JQJ is a fulcro expert and i think he's using re-frame at his new day job now?

I wouldn't consider myself an expert in either. However, I did choose fulcro over re-frame for my current application. I'm actually debating your question myself. I have parts of my application that are well suited to the subscription model, so I ended up building a mini implementation of re-frame within fulcro. I still like the general model of fulcro much better - being able to see the data straight in the db without having to use tooling to see the values of the subscriptions is a huge help. If Tony has a chance, he probably has a more thorough answer since we have discussed this a bit in the last week.

(I don't know if this is what you are saying, but I also find that a normalized db is far simpler to mutate against. I use the subscription side of re-frame only)

I think you mean normalized

.... words. they are hard.

Sure, and that's sort of where the question arose. If I'm using fulcro for a normalized db within a reframe app, what's the further argument for fulcro? I vaguely remember mentionings of rendering optimizations with the co-located queries in the days of om.next. But I didn't know if there were any more I should be aware of. I will say I like the idea of a set way for derived data, but that seems to have already been addressed lately with the subscriptions-render example

At the end of the day React does the heavy render lifting for both. When Fulcro is in charge of rendering it is a pluggable algorithm that need not even be tied to React. Fulcro’s rendering is essentially triggered by tx processing, also a pluggable algorithm. Thus the video where I can use Reframe to do the rendering…Fulcro doesn’t really care and isn’t tied to it very tightly. If you’re doing web only, like Reframe’s derived value model, and want to mix them, give it a shot. I’ve not tried it in any larger program, so I have no idea how good it would actually be. Personally, I’d rather see a derived data system as a plugin to Fulcro itself.

which is why I made those other videos…hoping to inspire library authors to contribute something: I’ve left all the hooks and demos of how to use them 😉

There are all sorts of possiblities, and I’m open to creating more hook points if library authors see a spot I’ve not made accessible enough.

Sure, and would love to contribute to that. In the videos, you suggested going the hooks/subscription route, right?

Yes, @U5P29DSUS and I were talking about that, which is what inspired the videos. I wanted to show him the options, but figured others might be interested

so, the React hooks route is tied to react, but when tied to render could be the cleanest end result, I think

Gotcha, is your implementation based on the hooks example @U5P29DSUS?

It’s also a nicer solution, in many ways, over the floating roots stuff I added recently.

The main downside is that some features of other nses use the query composition (i.e. dynamic routers use it to find nested routers)….but if used only at the “leaves” of the UI graph, it could be quite nice.

No, I wrote it in a weird way. I haven't used hooks before, and I didn't know that I could use the internal fulcro indicies for optimization. I'm planning on writing a hooks based system in the short term for my own needs. I'll be publishing it as a library if someone wants it.

Perhaps you should both do quick-n-dirty prototypes that show the basic outline, and perhaps we can all meet up and discuss pros/cons after a bit of experimenting?

Cool! Yeah, I'd be interested in that

Yup. Sounds cool. Actually, I think you wrote 80% of it for the video....

well, I would be interested in seeing what your thoughts are on how to actually deal with data dependencies in ways that are nicely visible during development. You know I prefer navigable code to event systems…but whatever works. a bit of R&D will help shed some light

Would rendering a signal graph in devtools do it? I know it's not navigable code like functions are, but it does give visibility

I'm not even sure if that's what you're actually doing @U5P29DSUS

It kind of is. I have a really really shallow graph, so I kind of know where everything goes.

I don’t want to limit options. I use events in UISM. I’m just encouraging you to think about scalable solutions on large projects.

i.e. do we really need subs that can consume subs, or is just composing functions the calculate the result acceptable?

what are the MUST have vs nice to have vs. features that sound good but actually create incidental complexity that outweighs the benefit.

Sure. I was thinking about re-select which as a "lazy" graph of nodes. One node doesn't update until what it depends on does.

A way to reduce computation

But I think that's done all through memoized functions?

right, but that’s an optimization…is it opt-in, or do I have to buy that complexity to do anything?

it also introduces caching: a huge source of bugs

Sure

remember that you have a superpower: normalized data. Doing a diff on that is trivial, esp when you know what idents you’re “listening to”

moving that into “hidden” places like atoms with watches makes it harder to see, and requires you invent addl ways to optimize

Makes sense

The subscriptions hook example doesn't place anything in the db, right?

consider ideas like reifiying the signal graph into the acutal db…then a dependency is as simple as a ident + optional field

It just querys?

don’t remember…you watched it more recently than me 😜

lolol

I can play with the example to be sure

I think it's possible to just use composition.

; given functions of the form

(defn step-fn [{:keys [whatever you need] :as fat-map}]
  (assoc fat-map :step-fn-result ...))

(defn step-fn2 [{:keys [whatever you need] :as fat-map}]
  (assoc fat-map :step-fn-result2 ...))


;; use meta {:changed? ...} for optimizations?
(defn memoized [function args])

;; use a composition fn that uses some memoization (backed by fulcro-db itself?)
(defn compm [& fns]
  (fn [& args]
    (let [fn-order (reverse fns)]
      (reduce ...))))

Since memoized is shared, we can take advantage of de-duplicated calls. using some form of :changed? could stop propagation. Maybe this is cheap enough that we run it for all possible registered live subscriptions on every render, since :changed? would halt it asap.

Could swap out compm for just comp when testing. Works with normal functions.

Maybe add a macro that keeps track of dependencies and results, and have a dependency resolution algo that simply gives you the order of functions to execute.

I dunno, the more I think about it the more I like it.

like I said: quick and dirty real demo with just enough complexity to prove the model would be nice

avoid macros…they can always be added later. Keep it as simple and clear as possible using functions and data first.

worry about sugar (much) later

@U5P29DSUS So you're thinking of keeping the calculated values in the fulcro db?

@U0CKQ19AQ Right, I'm just interested in the first part for now. @U1RCQD0UE yeah, but not for any really particular reason. If it's just normal functions, introspection is easy enough.