Fork me on GitHub
#reagent
<
2018-05-22
>
theeternalpulse00:05:49

Yeah, I just wonder is that example is out of date

gadfly36100:05:32

I haven't used track myself, so I'm not sure, but it's possible it is dated. CC @lee.justin.m

justinlee01:05:43

I don’t actually know how any of that internal tracking stuff works. @pesterhazy was thinking about doing a pass over that material

justinlee19:05:16

is there a way to expressly tell reagent that you want a re-render when a particular piece of state updates? i have an issue that I’m not getting updates with an external library using a render function because the deref doesn’t happen during render. I could just to a pointless deref and ignore the value but i feel like there must be something cleaner

theeternalpulse02:05:49

I see some references to forceUpdate in the impl functions in reagent, maybe you can use those.

pesterhazy10:05:07

could you describe the issue in more detail?

pesterhazy10:05:58

there have been times where I wanted to rerender a component explicitly and more often than not in turns out there's a better way to do it (e.g. lifecycle methods)

justinlee15:05:40

this was an issue with using react virtualized’s InfiniteLoader component wrapping the Table component when rows can update locally (e.g. with click selection). the issue here is actually that i don’t know how to do it properly in javascript either. in the end i’m just wrapping and updating everything as props. i’m getting an annoying flicker on re-render but i’ll just live with it.

justinlee15:05:34

because everything is done with HOCs and render funcs, the only way to make this work sanely with reagent is to pass the reagent atoms as props so that you can be sure everything gets derefed

mhuebert11:05:23

@lee.justin.m I think deref’ing at the appropriate time is a perfectly fine way to declare a dependency relationship, as reactivity systems like reagent are specifically built to pay attention to that, but I agree that it does not communicate intent well on its own. In a case like this I might do something like (def watch! deref) in a utility namespace somewhere, so that instead of seeing @the-ratom in the body of a function you would see (watch! the-ratom) which is more obvious. *unsure of the best name, maybe it depends on how you like to think about the way reagent works. depend-on!, react-to! also come to mind.

justinlee17:05:57

That’s an interesting idea. Basically I’ve been defeated a bit by the complexity of what I’m doing and the only problem I have is that I get a flicker when I update one of my rows. That usually means that the dom is getting an update it shouldn’t but wow is it hard to debug with these HOCs.