| 16:35 | <littledan> | putting the user code lexically nested inside of the framework code doesn't really demonstrate the example very clearly |
| 16:36 | <Willian Martins> | Justin Ridgewell: Does this proposal solves the pattern of piling up data in request object in node and pass it around the application? |
| 16:37 | <Justin Ridgewell> | I think you mean where you put framework data on the req object so that it can be passed around? |
| 16:37 | <Willian Martins> | Yep |
| 16:37 | <Justin Ridgewell> | Then yes, you could store that in an AsyncContext instead |
| 16:38 | <Justin Ridgewell> | You won't need to pass the req object around anymore to get the context data |
| 16:38 | <Willian Martins> | Thanks. I wanna pitch this proposal internally, and I'm looking for internal use cases. |
| 16:39 | <shu> | it'll be faster to just pass it around though... |
| 16:46 | <Justin Ridgewell> | In pure access-to-the-value terms, yes, it'd be faster to have a parameter or prop on a param |
| 16:47 | <Justin Ridgewell> | But I think that discounts the use of 3p code that is not aware of, eg, the req value and won't pass that around |
| 16:47 | <Justin Ridgewell> | So we have an over reliance on closures to capture the req and that closure gets passed to 3p code instead |
| 16:48 | <Justin Ridgewell> | I wonder if the closures are actually going to be slower than just the map access that AsyncContext gives you |
| 16:48 | <Justin Ridgewell> | Because closures wouldn't be required, I can start using static module level functions and pass data via context |
| 16:50 | <shu> | not understanding the closure point -- if it's in fact threaded through by user code, there're no closures involved, just passing something through? |
| 16:50 | <shu> | but if closures are in fact involved then i agree |
| 16:50 | <littledan> | The "making hooks work at all with async functions" case seemed pretty important |
| 16:54 | <Justin Ridgewell> | not understanding the closure point -- if it's in fact threaded through by user code, there're no closures involved, just passing something through? |
| 16:55 | <Justin Ridgewell> | The "making hooks work at all with async functions" case seemed pretty important |
| 16:58 | <ljharb> | i see tons of closures as well - in react, the two approaches are either “prop drilling” or something on the side, like context or a flux store, and the problem with the former is that intermediate components often do not know or remember all the things they need to pass down. |
| 17:01 | <littledan> | I guess the question isn't "are there closures" but "can the user code close over stuff from the framework to make it so it doesn't need to pass things around all the time" and that answer is often no |
| 17:03 | <littledan> | to Mark's point: the update in the AsyncSnapshot API would be simple: You'd pass a positive integer into the AsyncSnapshot constructor to indicate how many times it can be restored. If you write Infinity, the task termination callback is never called. Mostly you'd pass 1; maybe that'd be the default constructor. |
| 17:04 | <littledan> | maybe an "increment" or "clone" method would be added in conjunction with this |
| 17:06 | <bakkot> | can't you just store something mutable in the context and then mutate it manually? |
| 17:06 | <bakkot> | why do you need the base API to be expanded? |
| 17:13 | <littledan> | Oh right that too maybe |
| 17:14 | <littledan> | No the issue is that you want this to work out of the box with promises |
| 17:15 | <littledan> | Calling .then should increment the count, and when the reaction runs, it should be decremented |