@wilkerlucio ❤️ Also: > there is a bug in the current Clojure writer, it -would be nice with a link?
For various reasons, I’m trying to replace the frontend for an application, but need to leave the server in place. Am I inviting lots of pain into my life by trying to use Fulcro only for the frontend?
I’ve read the first three chapters of the Fulcro book, and have started on the chapter about remotes, but I’m wondering if I’m going too far against the grain by not using a Fulcro backend as well.
I have used it to tie to multiple backends, I have like 6 different apis from 6 different backends all tied to 1 fulcro frontend.
I’m glad to hear it.
How was it to tie in the auto-normalization functionality?
I just wrote resolvers for each thing I wanted that pull the data from the api, and put it into the format pathom wants, the auto-normilization happens transparently from there.
Just as an example, I have an api that gives back: {:site_id 1 :site_name "SomeName"}. Pathom and fulcro want namespaced keys, so I transform that to {:site/id 1 :site/name "SomeName'}.
Fulcro 3.3.3 on clojars. Includes a nice generalized error-boundary macro based upon code originally written by @currentoor. I made the actual error rendering customizable, and made it so that you can get around the immediate React restriction of only being able to catch errors that happen within children. See https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/react/error_boundaries.cljc#L63 Book updated with: http://book.fulcrologic.com/#_react_errors
Awesome! I was thinking that something like this would have been useful...