Fork me on GitHub

@fjolne.yngling I’ve pushed 3.0.13-SNAPSHOT, which should fix that bug

👍 1

If you use websockets, you’ll also need to update to 3.0.5-SNAPSHOT


testing…but will have formal release soon


Hi there! I use the version 3.0.12. There is a strange something about the state machine's handler, it seems that uism/assoc-aliased won't work before the dr/change-route. the codes like this: :event/goto-club-page {::uism/handler (fn [{::uism/keys [event-data] :as env}] (uism/assoc-aliased env :selected-club (:club/id event-data)) ;; it doesn't work. (dr/change-route SPA ["main" "currentClubPage"]) )} :event/goto-club-page {::uism/handler (fn [{::uism/keys [event-data] :as env}] (dr/change-route SPA ["main" "currentClubPage"]) (uism/assoc-aliased env :selected-club (:club/id event-data)) ;; it works. )} Have anyone know why is it?


Just a slack tip: You can enclose multi-line code snippets in triple backticks.


You have to thread the env through, and return the new env


there are no side effects in UISM functions


in other words: You must return updated env


@tony.kay it's ok, thanks for your help!


@tony.kay thanks a lot, it’s working as expected now, pre-merge made the app’s logic much cleaner

Robin Jakobsson10:12:18

coming from React/ES6-land: is there any equivalent of PropTypes declarations in Fulcro (for requiring certain props)?


@jakobssonrobin Clojure spec is your friend. As you learn more about Clojure and the general approach to name-spaced keywords (which stems from RDF) you’ll find that hard-core schema hurts you more than it helps. You’re also in a language where new “syntax” is just a macro away…so, the short answer is “not exactly”, and the longer answer is “sort-of, but a bit different”, and the more involved answer is “you can easily get something better” (for example the options map on components is an open map, which means you can put your own nsed declarations (e.g. about prop specs) and then a simple wrapper macro could add in devel-time checking.

Robin Jakobsson12:12:39

Thanks, I will have a look at spec 🙂 . And I’ll give nsed declarations a thought.


Fulcro 3.0.13 and Fulcro Websockets 3.0.5 released. These fix some internal issues that were affecting correct operation of :pre-merge and load normalization.

👍 9

Is there a concise way to mark form fields as complete and then immediately check validity? Validation check requires the denormalized entity tree, and props aren’t updating that fast if I’m transacting fs/mark-complete! and then pass props to the validator. I’ve got 2 solutions: to manually denormalize required component from normalized state in mark-complete transaction and to use js/setTimeout. Both seem quirky...


You mean within a mutation, right? I should really add a convenience version of the function for that. You can denormalize things with com.fulcrologic.fulcro.algorithms.denormalize/db->tree and use the existing function.


or you could look at the implementation and write the helper that works on normalized state.


Basically you define what it means for a field to be complete, and the ::fs/complete? entry in the form config tracks completeness…so you can always figure it out in a mutation from base data that you have easy access to. But if you’re trying to use a generated validator from make-validator, then using db->tree is probably easiest.


There is a form-state helper function called update-forms that walks over your (potentially) nested for via normalized state. You could combine that with an atom in a helper function to build something that could directly walk normalized state and use your same predicate you gave to make-validator . I supplied update-forms as a helper for building whatever you might need that works across form sets.


Thank you for the ideas, update-forms sounds promising. But I’m using spec validation, and there’s another caveat: I must check validity before calling dirty-fields, because it is instrumented (?) and fails on my specs. So I can’t just pass the dirty diff to the mutation which would mark the form complete, check for validity and submit — spec fails before that. So my implementation with db->tree within a mutation failed and I went with js/setTimeout.


To the first question, I meant within a mutation + in the same transaction (in case we’re using fs/mark-complete!, so that mutations would execute in the right order, but now I come to think about and it seems to not really matter, as optimistic transactions’ actions are executed asap, right?)


That’s kinda funny how I ended up implementing a similar transactional mechanics in re-frame for past projects, before learning about Fulcro. Thought I was doing something wrong cuz I haven’t found anything like that for re-frame back then. Good to know it wasn’t such a misconception on my side. Better though to finally switch to a battle-tested implementation;)


So, you are using instrumented specs to throw on validation? That seems very off to me. There’s nothing wrong with using specs, and there are API calls to evaluate those when/where you need to. Am I missing something?


No, I’m using specs only for fs/get-spec-validity, I’m not instrumenting anything. But Fulcro somehow throws on calls to fs/dirty-fields, when my fields aren’t valid.