Clojurians Log v2

You can redefine effects.

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

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?

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

@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.

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

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

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.

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

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.