@profil: Stab in the (very) dark - do you have an erroneous apply or into hanging around?

@colin.yates: do you have recommendation on how to debug these problems in general?

hi @ordnungswidrig I often find that I will take a series of steps and then I wil do something stupid and get an error message which doesn’t illuminate the solution in anyway. The only recovery process I have found is very regular commits and then rebase before pushing. In other words, no, not really . Also, there is a large amount of errors that disappear once you get more familiar with the tools.

That’s dissapointing. I wonder if one you wrap a „linter“ function around what’s returned form the component renderer which wars in a more sensible way?!

sorry to disappoint . I’ve never felt the need for that as I have never run into these sorts of errors.

it is also worth noting that figwheel also solves this ‘multiple steps, which one failed’ to a large degree if you save frequently.

However, I find most of the complexity is in my domain code not the rendering code so it doesn’t really help that much. I run into far more of ‘why is it that value’ rather than ‘why is it rendering like that?'

That’s right. I find myself refactoring components and „suddenly“ everything breaks

for these cases the error messages are sometimes not very helpful.

eventually I'll throw some ducttape treewalk validator together.

Hi everyone. Wanted to talk a bit about what people are doing to separate view vs application state, if they're using a single atom for all their application state. I'm doing something like this in one app, and would appreciate some input: (def app-state {:views {} :session {} :domain {}}) :views stores state that specific components need to retain - a use case for this is if you scroll down on a page, follow a link, then go back, the previous scroll position should be retained. This is only useful for non-reusable components, like the one that wraps your entire homepage. :session stores state that isn't specific to a single component and isn't something from the problem domain. This might be something like filter options you've applied to a list (though that might also go under :views) :domain is pretty obvious - if you're making a todo app, it's your list of todo items.