Clojurians Log v2
fulcro
Got it. Many thanks for sharing your thoughts.
I have a problem coming up with a good solution to compose mutations.
Like doing a redirect after a successful sign up.
In 9.3.9. Result Action for Pessimism there is an example where you submit a new mutation in the ok-action section, thats what I always did.
But what if I don’t always want to redirect? Having a sign-up mutation and a special sign-up-and-redirect mutations seems odd.
I have the feeling I am missing something here…
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.
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.
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
I want to set up a very basic GitLab CI pipeline just to execute my tests. Any pointers as to how to implement that?
Thanks, going to have a shot at using this as a starting point.
@randumbo 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 <https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb>
- apt install -y ./google-chrome-stable_current_amd64.deb
- npm install
- npx shadow-cljs compile ci-tests
- npx karma start --single-run@tony.kay 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: