Clojurians Log v2

let’s say I create an entity optimistically in the action of a mutation keyed on a tempid. I transact that server-side and then want to return that “fully resolved” entity with additional data. what’s the best way to do that? to me, I could either parse the result in ok-action or use m/returning. the latter feels simpler but not sure how tempid resolution works with m/returning. any ideas would be much appreciated!

No, not in the magic interpretation. If you write initial state as a fn, then you can do whatever you like with the params.

The problem is without a param ns the magic could get confusing with respeect to what is a prop (for error checking), what is a literal keyword, and what should be pulled from “params”

returning

tempid resolution works in the correct order, so tempids are resolved first (moving the in-db version you had to the correct location), and then the merge

So, as long as your mutation returns tempids remaps, it should be fine. This is, in fact, what RAD’s forms do. They save (new or modified), and they add a returning on the save mutation to return themselves to make sure you see everything that might have changed in db.

Ok - got it. That makes sense. :thumbsup:

Do we have examples of fulcro used in live/production systems?

I have worked on more than one commercial project of over 60kloc, and the one I’m currently working on is over 120kloc. None are open source.

Most have been b2b, so not really consumer facing

I started with fulcro roughly a year ago and we're running in production on AWS / Datomic Ions. No complaints so far 🙂

One question: What are your thoughts on versioning the API? I love how close coupling is between client and server. It significantly reduces overhead (I even wrote a late night love letter to Fulcro the other day: https://world.hey.com/aleksander/why-i-clojure-fulcro-edition-f12b9976) However, unlike web, I can't guarantee clients will be up to date on mobile - and I feel like the risk of "accidentally" breaking old clients might be quite large with Fulcro. I believe and hope I can do it by setting up proper guidelines for mutation/resolver changes, but I was wondering if anyone else has given this any thought?

I'd like to wrap a js react component in the factory helpers (like from https://github.com/fulcrologic/semantic-ui-wrapper/blob/master/src/main/com/fulcrologic/semantic_ui/factory_helpers.cljc) but with support for :classes [...]. Could someone point me to the helper function that I could use to turn that vector into a classNames string?

We have had an internal app for a year... Are you asking in general or about publicly accessible stuuf? I believe people have built a lot but most not public...

No. Can you follow what Rich propagates and never break clients? If you need a breaking change introduce a new name(space).

Hmm, if you absolutely had to make breaking changes in your pathom parser I think it'd be best to maintain the old version(s) and make a new one, right? That could be accomplished by having different parsers run on different http endpoints, or by requiring that all requests come in with a :api-version keyword or sth similar

looks like it's here: https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/dom_common.cljc#L104

So here’s my take after 5 years of working with the system: It has never been an issue, assuming you follow a few simple principles: • A namespaced keyword goes with a particular fact. Period. Aliases are acceptable but should be avoided if possible because the are confusing. The primary directive is never change the meaning of a keyword • Extend by accretion, which is in one of Rich’s talks as well. If you have a mutation and you need a new way of dealing with things, then add a new mutation. Put it in a new namespace. • Don’t remove stuff. You can stop asking for it. You can change the security if need be (which of course is a breaking change, but is a global constraint, not an API specific one). The fact that a resolver is still sitting around to resolve something that no one asks for isn’t really a big deal. Clients pull what they want. The problem with REST APIs is that they have to be pre-designed to fit each use-case. The client being able to pull what it wants is very robust over time and evolution. Got new things to read, add them in! Got new ways of getting from A to B, add in a resolver for the edge. Want a new way to talk about an existing thing? Add a new keyword that resolves to the new variant. I do not expect to version an EQL API. I just don’t ever see the need.

You should watch this for sure: https://www.youtube.com/watch?v=oyLBGkS5ICk&ab_channel=ClojureTV

at least the first 30 minutes. This applies to Fulcro network APIs perfectly

because they are functional in nature