Yes, defsc ultimately (in js) calls configure-component!. You could load all of your component options from some store, and use it directly. You’d have to use dynamic queries to update the UI tree’s idea of the data graph.

The whole system is designed around the possibility of doing exactly these kinds of things.

As far as attributes go in RAD: They are just maps. Those are easy to make and store however you want. You would have to make a more dynamic db plugin, but if you look at the existing code you’d see how simple that would be. The toughest part would probably be getting pathom to update its indexes, which could be as sample as just making a new instance of the parser as needed over time.

Thanks, Tony. That's very helpful. What's the best model to start with for creating a Mongo db adapter?

Thanks, @U0CKQ19AQ. That's very helpful. What's the best model to start with for creating a Mongo db adapter?

Look at rad kvstore

Sorry to continue with this @U0CKQ19AQ, but I want to make sure I am clear on the options. It seems that to use RAD my choices are to write a konserve backend for mongo (and integrate it with kvstore) or create a more direct RAD adapter. Given that time is a nontrivial issue here, I need a simple functional starting point, so I'm inclined towards the latter. What is the minimum interface that an adapter needs to support? It's not really clear to me from the existing adapters or the RAD book. I can easily get data into clojure in a nice form and can write Fulcro resolvers for it, but I'm not sure what the easiest way is to connect these to the RAD magic. Thanks for your help!

There isn’t really much magic on the back-end at all. You have to have resolvers that can resolve queries. The generated resolvers in Datomic are really trivial when you use the recommended approach: id in, attributes out. The main thing an adapter really does is save, which is just a conversion of a normalized diff (see Fulcro form-state) to a database write. Really that’s about it. In Datomic that’s just a few hundred lines. But, since the normalized diff is a complete description of a graph change, it gives you a fully-general write mechanism. At that point you can write your server-side mutations in terms of form save (manually generate a diff and pass it to the form save, which in turn will use the db adapters and distribute the values to the corrected db(s)).

The normalized diff is trivial: {[:person/id 3] {:person/name {:before "Bob" :after "Joe"}}}

From there an adapter could support additional helpers. E.g. schema generation, schema validation, reverse eng tool -> attributes, etc. etc. But really the only things the front-end needs are the ID-based resolvers and diff->txn functionality.

That's very helpful. I appreciate it!

The initial html for the app is generated dynamically here: https://github.com/fulcrologic/fulcro-rad-demo/blob/f840996486fcedfaa3871443ca7499ed3a3cf62a/src/shared/com/example/components/ring_middleware.clj#L16 so you shouldn’t need to create one manually!

thank you, that makes more sense. I was mistakenly using the the shadow-cljs server url instead of the one spun up dev:datomic