disclaimer: I’m a complete newbie. My intuition is that the validity of your field should be encoded in the data-model from which the other component pulls this information. Is that so?

The file to be uploaded is a csv file and the attribute that needs to be valid is the headings of that file. I want the user to be required to input valid list of headings (eg./ date,desc,money) before uploading the file becomes possible. This might mean the upload button becomes enabled. I want to develop an intuition for solving these kinds of problems using the mechanics available in Fulcro RAD.

The built-in renderer doesn't have the concept of hiding an entire subform. remember that RAD's model is one of gradual "outgrowth". In this case since the renderer does not support what you need, your choices are: 1. Create your own rendering plugin (based on the existing one) and add what features you need 2. Submit a PR to the built-in one. I'd be willing to add support for that on the ref attributes or maybe better as a lambda on the subforms options. 3. Add a custom ref container style. That let's you customize how refs are rendered. This is related to 1/2. 4. Take over the rendering of the form by simply giving the forms a body, in which case you can do whatever you want.

Take a look in RAD form.cljc:127, ref-container-renderer

and its usage in the SUI plugin form.cljc line 212

Items that come to mind: • Using React state for fast local updates, commonly useful for: • Using local state for things like animation control, etc. • Storing certain things in atoms for global access, such as a map from React refs to components so you can do things like manage focus or attach hovers to the DOM via external libs So, yes, there are definitely use-cases. However, if you are rendering a core bit of your application domain, you'll be better served using Fulcro for that

Thanks @U0CKQ19AQ. I'll lean heavily towards using Fulcro except for the most inconsequential UI changes.

Making little wrapper functions to emit some (common) reusable DOM is fine. You can also use the new raw components support in 3.5 to do pure hooks-based low-level functions. I've not documented those very well yet, but the new stuff is quite powerful and less verbose. See raw-components/nc, hooks/use-component, etc. defsc gives you the rough equivalent of a React PureComponent with automatic shouldComponentUpdate, and more importantly integrates you with the graph query and data normalization...but sure, it is quite common to just write some boilerplate UI in a plain function and just call it.

To clarify: You still need 2 arguments, ie [_ props]

Fulcro already has built in loading state tracking, but it's opt-in - see the load marker param to load! Fetching in willMount can lead to cascading remote calls - A will mount and loads its data, it renders its child B that will load its data,... Loading the whole relevant subtree for all the child nodes at once eg using dynamic routing and :will-enter will give you much better performance. And works just fine in practice, I haven't felt any need for auto loading.

Btw have you seen https://fulcro-community.github.io/guides/tutorial-minimalist-fulcro/?

This is a pretty interesting idea, one thought of how to go about it is to add a new property to defsc like ::subscriptions or whatever name you want, which would be the opt-in parts of the graph that result in remote calls. This could be a data structure like a normal fulcro query but maybe has which remote to use and the caching policy to use. You can then make your own macro that wraps defsc and handles the details of fetching the data. Notes on how to wrap defsc can be found in this talk by Wilker: https://youtu.be/R_XPwi0Kiwk?t=246

Hi @U0522TWDA, thanks for your response 🙂 Yes, I’ve seen it, I think you’re the author, right? Thanks a lot for such a valuable learning resource 😄 Yeah, I read about the cascading issues in the tutorial, and I thought auto-loading could be done without cascading, some work on the backend may be required, to have a bulk query resolver and recursively resolve queries using IDs from previous resolved queries in the same bulk query request. I also have seen the loading tracker state via markers, and this could be used as a join in defsc queries to get the request state, but would be nice to be auto-hooked for bulk query “global” request. My point with this post was not having to write such code. I liked apollo’s declarative data fetch, where you don’t need to think about handling the fetch itself, it just happens and is there for you for you to use in the view. I mean, I’m ok writing such code to manually load the data, but wanted to explore the possibility of having declarative fetching in fulcro, as component’s know all data they need in the UI tree. 🙂

as Jakub mentioned, there are existing pieces in fulcro that should make adding this sort of thing pretty straight forward (the remotes abstraction and load state tracking)

@U051V5LLP Yeah, I figured it should be something easy to do with current fulcro’s building blocks. I’ll try something to go over defsc’s metadata and traverse the UI tree queries and see what happens 🙂 Subscriptions would be nice, but that’s a complete different beast. However, as Tony said in one of his videos, Fulcro is ready for such real-time features to be plugged easily, the hard part is to notify the client when the data changed in a scalable way 😛

Ah, I didn't intend for subscription to imply live updates, just a way to distinguish the parts of the query that you want to result in remote calls

Ah got it, yeah. I think wrapping defsc in a macro is an overkill. I think traversing defsc’s metadata should be doable, I’ll check the video you suggested ❤️

I think wrapping defsc is the way to go, one of the great parts of fulcro is that the component options is an open map, so you can add whatever extensions you want there. Here is an example adding re-frame subscriptions by wrapping defsc and adding a new key, if you want some inspiration: https://github.com/dvingo/fulcro-re-frame-playground/blob/main/src/main/dv/fulcro_re_frame/play/client/fe_macros.clj#L134

Nice! Yeah, I thought it was going to be an open map with data everyone can just use 🙂 — fulcro was created by a clojurist after all 😉 As a second thought, I think you’re right. Maybe I need a macro because I’d need to hook the “I’m going to show” callback (whatever that will be), and for that I’ll need to change the component somewhat. Another option would be to let the user handle such hook, and call a function to register to the global bulk query request that is going to happen.

after writing that I think I prefer letting the user decide when to register his component 😛

or both… 🙂 … anyway, thanks a lot for your input! ❤️

for sure! I'm interested to see what your explorations uncover 🙂

I would encourage you to look at the new hooks and lightweight/raw component stuff in 3.5. Subscriptions have a lot of complexity to their simplicity, and I decided long ago that providing them "out of the box" was a bad idea...too many things to configure, opinions to satisfy. It's actually quite trivial to implement them, dependning on your requirements. The React effects hooks, combined with raw/nc and hooks/use-component can get you quite far.

I'm sure coming up with a use-subscription would take all of about 30 minutes for the base case. I've got a component I wrote for doing a dropdown that auto-loads the options that looks like this:

(defsc ProductInventory [this {:product/keys [id]}]
  {:use-hooks? true}
  (let [Inventory (hooks/use-memo (fn [] (rc/nc [:product/id
                                                 :product/sku
                                                 [df/marker-table ::inventory]
                                                 {:product/calculated-stock [:location/id :location/name :inventory/quantity :inventory/unit-cost]}]
                                           {:initial-state (fn [& _] {:product/id               id
                                                                      :product/calculated-stock []})})))
        {:product/keys [sku calculated-stock] :as props} (hooks/use-component (rc/any->app this) Inventory {:initialize?    true
                                                                                                            :keep-existing? true})
        loading?  (df/loading? (get props [df/marker-table ::inventory]))]
    (hooks/use-effect (fn []
                        (df/load! this [:product/id id] Inventory {:marker ::inventory})
                        identity) [])
...

nc lets you generate a dynamic component on the fly with auto-generation of ident based on the first ID field found in the (nested) query. It actually generates a TREE of anonymous components for normalization. Then you can hook that up with use-component to get the data from state, and use-effect to trigger the load. Generalize that and you've got use-subscription

arguments are: tree query, id of thing to load. Output is the props of the loaded thing.

use-memo is just so it doesn't keep generating new anonymous components on every render

@U0CKQ19AQ The legend himself has graced us with his presence! 🙂 Thanks, Tony. I was actually looking at rc/nc because I wanted to mimic what you did with form-config-join, which uses it. Wasn’t quite sure what it did, but after your explanation I think I get it. However, I’m building a toy project first before going deep into fulcro’s internals. There are a lot of concepts I need to get my head around still. Thanks for the amazing framework, I have gone through a cycle of “screw this, it’s too overwhelming” and coming back again because all design decisions are just beautiful, every bit there that’s “hard to learn” is there for a reason, to make things simpler in the grand scheme of things… banging my head against the wall has been worth it every single damn moment ❤️

this is really cool! I have try out these nc and hooks tools..