search

ralusek / reselectie

MIT License
108 stars 6 forks source link

Debugging / Maintaining Selectors #1

Open wildeyes opened 6 years ago

wildeyes commented 6 years ago

A common problem with selectors is that they're not easy to debug. Do you have an idea of how "transparency" could be built in to reselectie to make it easier to understand what each selector does?

ralusek commented 6 years ago

Sure, I think it could have some metadata associated with it to let you know which of the input selectors were responsible for a reselect trigger.

That way you could be seeing an expensive recompute being triggered, and if you were wondering why that was happening you'd be able to see "oh, okay, it's this second selector is changing every time, so it's triggering a recompute."

I think it would be easy to come up with an interface for this, like if you passed another function or an config object this could output some metadata that could be logged. The only problem is that in order to grant this that sort of introspection, it necessarily requires additional code.

I think one of the reasons people like this library is because of how small it is, but I HAVE done some work on a more in depth memoization function where I'd be happy to add some introspection to? What do you think? Is that the sort of transparency you were referring to?

wildeyes commented 6 years ago

Yes. There are some implementations that offer this introspection, but they require having a string before the selector, to identify it, which sucks. I'm not sure how to do it otherwise though.

On Sun, Nov 12, 2017 at 11:34 PM, ralusek notifications@github.com wrote:

Sure, I think it could have some metadata associated with it to let you know which of the input selectors were responsible for a reselect trigger.

That way you could be seeing an expensive recompute being triggered, and if you were wondering why that was happening you'd be able to see "oh, okay, it's this second selector is changing every time, so it's triggering a recompute."

I think it would be easy to come up with an interface for this, like if you passed another function or an config object this could output some metadata that could be logged. The only problem is that in order to grant this that sort of introspection, it necessarily requires additional code.

I think one of the reasons people like this library is because of how small it is, but I HAVE done some work on a more in depth memoization function where I'd be happy to add some introspection to? What do you think? Is that the sort of transparency you were referring to?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ralusek/reselectie/issues/1#issuecomment-343769852, or mute the thread https://github.com/notifications/unsubscribe-auth/ABk1jBzUaZluEoroBVsmx38rSI32jhyBks5s12R3gaJpZM4Qa8jT .