Fork me on GitHub
#reagent
<
2015-11-09
>
colin.yates08:11:04

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

ordnungswidrig08:11:31

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

colin.yates08:11:47

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 simple_smile. Also, there is a large amount of errors that disappear once you get more familiar with the tools.

ordnungswidrig08:11:44

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?!

colin.yates08:11:32

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

colin.yates08:11:19

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

colin.yates08:11:53

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?'

ordnungswidrig08:11:10

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

ordnungswidrig08:11:43

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

ordnungswidrig08:11:16

eventually I'll throw some ducttape treewalk validator together.

tomc23:11:13

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.