-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Conversation
this is awesome. Does it get super behind though? |
In my testing it gets behind by a few seconds if you're doing heavy operations (e.g. unmount/mount a FixedDataTable multiple times without giving it time to breathe). For React Motion-like demos with tons of fast updates, it gets behind by about half a second so it’s “trailing” updates at a slower speed. It’s a bit hard for me to say if this is confusing or not unless we let people use this, and wait for complaints. |
@@ -197,34 +214,45 @@ class Bridge { | |||
this._inspectables.set(id, {...prev, ...data}); | |||
} | |||
|
|||
sendOne(evt: string, data: any) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one seems dead, I couldn’t find calls to it anywhere.
I'd love for there to be an indicator that we're lagging, to reduce confusion. maybe add a flag to "send-many" indicating how many evens we still have to send. Then in the UI we could show a loading indicator if that number gets above 100 or something. That doesn't have to be part of this diff though |
I did some tweaks to better handle real world scenarios, now it’s consistent pretty fast even with large number of events so I think maybe we don’t need an indicator. |
This reverts commit bf2601e.
* Slice flush into small parts * Schedule in a smarter way
* Slice flush into small parts * Schedule in a smarter way
This is a proof of concept of slicing flush into small parts.
React DevTools currently heavily slow down big apps like (PE) with all the synchronous work.
Example before:
Example after: