You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal here is to avoid complete rerendering of entire notebooks every time a bit of prose (or block later in the sequence) updates. This can get expensive if there are a lot of visualizations or other stuff to render, and just isn't necessary. This feature will get even better once we have finer-grained dependency resolution between blocks.
Here's how I think how this will work:
Right now there's generally some kind of template specified for these kind of files, since they implicitly define a sequence of blocks, and therefore have to be placed in some kind of container.
We can send this container to the client as soon as evaluation is submitted, along with a sequence of hashes corresponding to each of the blocks.
For blocks which don't need to be re-evaluated, the hash should remain unchanged.
On the client, components are generated for each of the blocks, but shouldn't have to rerender for blocks corresponding to hashes which haven't changed.
Question: Will have to verify that this works as expected with the outer container (reagent) component changing; Will all of the children have to rerender if the parent is? If not, can we use a form-3 component (and react methods) to override this?
As blocks of code complete evaluation on the server, we send the results to the client, keyed by hash, cache them in state there.
This caching will trigger reaction (or cursor?) updates which then trigger the new results to update.
Will have to do garbage collecting to make sure we aren't keeping around components that aren't needed any more.
Not only will this improve performance, but will make it possible to see debugging or error messages per block (and maybe even getting undependent downstream blocks to still render). It's a bit of work, but I think well worth it.
The text was updated successfully, but these errors were encountered:
The goal here is to avoid complete rerendering of entire notebooks every time a bit of prose (or block later in the sequence) updates. This can get expensive if there are a lot of visualizations or other stuff to render, and just isn't necessary. This feature will get even better once we have finer-grained dependency resolution between blocks.
Here's how I think how this will work:
Not only will this improve performance, but will make it possible to see debugging or error messages per block (and maybe even getting undependent downstream blocks to still render). It's a bit of work, but I think well worth it.
The text was updated successfully, but these errors were encountered: