So what I can do is doing the redirect based on the application state. This is fine when I can redirect if, for example, I have a valid session in the state after a successful login. But this seems quite cumbersome in some situations. (like if the remote mutation changes some text and I would have to compare the old and new state for changes)

You can compose st->st functions: https://book.fulcrologic.com/#_mutation_helpers

If they are what you want consider also using:

[com.fulcrologic.fulcro.algorithms.normalized-state :refer [swap!->]]

Thanks, but this does not help with mutating based on the result of another mutation. I don’t want to write something like this:

(defmutation sign-up [{:keys [username password]}]
  (action [_] (do-whatever))
  (remote [_] true))

(defmutation sign-up-with-redirect [{:keys [username password]}]
  (action [_] (do-whatever))
  (remote [env] (m/with-server-side-mutation env `sign-up))
  (ok-action [_] (comp/transact! [(redirect!)])))

(defmutation sign-up-with-confirmation-alert [{:keys [username password]}]
  (action [_] (do-whatever))
  (remote [env] (m/with-server-side-mutation env `sign-up))
  (ok-action [_] (comp/transact! [(show-confirmation!)])))

I didn’t know about swap!-> . Thanks

Can the ok-action see the mutation params? Then you could (if :redirect? (transact!...))

I guess the result the action sees might also include the original transaction o you could look there?

I would argue that having mutations with descriptive names results in more maintainable code than mucking around with parameters does.

BTW I believe I remember reading in the book about passing info about UI-only concerns through a (remote) mutation so that they could be used in ok-action. Try to have a look there. Sadly, I don't remember any details.

Can I ask you both how you deal with such sitations? Do you just write a new mutation for each button or whatever in your application?

Yes - I'm happy to write lots of mutations and don't see doing so as some kind of failure. Interestingly when using either UISM or RAD the optimistic part of mutations disappears. Your UISM itself alters app state and has mechanisms to fire off to remote mutations and catch the returns. And with RAD app state is altered for you. So either UISM or RAD are ways to get rid of local mutations if you think their proliferation is harmful.

I did not run into the issue yet. I believe UISM can indeed be a solution.

It may be out of date. But you could look at this project: https://github.com/hhucn/decide

Thanks, going to have a shot at using this as a starting point.

@U01E3601UJW any luck? I have a current YML file that is working with them

I have to trim out company-specific stuff, but here’s what I’ve got (should work with basic fulcro template):

cache:
  key: one-key-to-rule-them-all
  paths:
    - node_modules/
    - google-chrome-stable_current_amd64.deb

default:
  image: clojure:openjdk-8-tools-deps
  before_script:
    - apt-get update

clj:
  script:
    - clojure -A:dev:clj-tests

cljs:
  script:
    - apt-get install -y nodejs npm wget
    - ls google-chrome-stable_current_amd64.deb || wget 
    - apt install -y ./google-chrome-stable_current_amd64.deb
    - npm install
    - npx shadow-cljs compile ci-tests
    - npx karma start --single-run

@U0CKQ19AQ I'm looking through Kaocha docs right now, trying to figure out if I want to use that at all right now... thinking it's better to stick with vanilla until I need more. I always just run my tests in the REPL (vim-iced) though, not even sure how to invoke it in the CLI... but I see it in your snippet there now, thanks.

I added that and a circleci one into template under sample-ci-files

the template is meant to have a lot of the things you need for a prod setup: config variance, testing that can run from CI/CLI, testing that can run fast from REPL, etc.

I just got my GitLab Runners up and going using a mock config. Haven't totally dove into the Fulcro side of it. This is going to be very helpful.

I hadn't looked in the template repo before. Wonder what other goodies I might find in there :thinking_face: