Got it. Many thanks for sharing your thoughts.
@reshef.mann Are you using Fulcro version 3.4.2+? The latest Fulcro Inspect requires that to work.
@henrik I'm using fulcro version 3.4.3
and fulcro inspect version 3.0.2
and see the same issue.
@dionysius.almeida The issue is strange because Fulcro Inspect is working fine for me... Make sure your Chrome version is up to date as well. Try setting "Site access" to "On Click" in your Fulcro Inspect extension settings. This way, when you use Fulcro Inspect, you need to click on the Fulcro Inspect extension icon to "activate" it. From your screenshot, you should click on the puzzle icon towards the right end of your navigation bar, then click on "Fulcro Inspect". Hope that manually turning on Fulcro Inspect can solve your issue of it not working all the time. The bright side is that you could still get it to work somehow, despite the workaround (i.e. closing and opening it again). Hope you can find a solution. P.S. You @ a different person, not me. I am @hk9861.
@hk9861 Thank you for your help. Yes I did @ a different person 😀. I did change it to "`On Click`" but it's the same result. I guess I will have to live with the closing and opening developer tools
for now.
@hk9861 Thanks! I was indeed using and older version (I cloned the fulcro template). It works fine now.
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.
1👍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: