p-himik 2020-10-19T01:26:14.155Z

You can redefine effects.

p-himik 2020-10-19T01:26:34.155200Z

Just call reg-fx again with the same ID and with a different implementation.

willier 2020-10-19T03:36:45.158200Z

hmm.. it's the effects that i want to test though. e.g. if the response is a 400 then x event will be dispatched or if 200 then the db should contain my data... something like that


Call the callback with the mocked response?

p-himik 2020-10-19T07:25:02.159100Z

I would just replace the URL with something that guarantees the required HTTP code.

Kamal Sadek 2020-10-19T15:14:03.162800Z

@p-himik The way we do it with our product, we only have views.cljs and control.cljs, where the control is responsible for all events, data, etc. and turning it into an easier representation that can be called out to by the views. While it does sometimes run into the issues that you describe (i.e. if we have extremely simple events / getters and setters), I think it's a bit less cumbersome than the 4 different namespaces described above, and the structure does help break things up, and keep things a bit modular. Just mentioning this because I'm also a bit curious as to how you organize things personally / how you recommend doing this. Do you simply have one ns for each Component / Page in the application? I've primarily used similar patterns that break things up like this (MVC, etc.), and it usually does help keep code cleaner and a bit more modular, but wondering if it's not as much of an issue in a Clojure based stack.

p-himik 2020-10-19T15:15:47.163100Z

> Do you simply have one ns for each Component / Page in the application? Yes, with some justified ad-hoc exceptions.

Kamal Sadek 2020-10-19T15:20:11.163300Z

Interesting, I'll keep that structure in mind then!

jmckitrick 2020-10-19T16:14:24.163600Z

What I’m aiming for is smart re-use. So a clickable button, for example, can be styled, etc but you pass in the event you want sent with the click handler, plus any relevant args grabbed from immediate component context. A table is more complex, but could be similar with a vector of column headers a vector of row maps. Anything special can be an event passed in and sent off with the dispatch call. Then a container could fire off events, subscribe to results, and pass those atoms down into components. Pretty basic stuff, really.

jmckitrick 2020-10-19T16:15:16.163800Z

But I want to make sure the namespaced keywords are an asset rather than an annoyance when it’s time to refactor.

p-himik 2020-10-19T16:19:42.164Z

I wouldn't put refactoring costs too high on the priority ladder. Otherwise, abominations AbstractSingletonProxyFactoryBean would appear. :) Both kinds of keywords are just keywords. You refactor them like anything else, especially if your development environment treats them as first-class citizens. The only way namespaced keywords can become cumbersome is if you move a keyword like ::x into a different namespace. Maybe your DE supports that just fine, and then there are no problems whatsoever. Maybe mine IDE supports that as well, but on average I move about one keyword every 2-3 months I'd say, so I never bothered to even check.