I’m trying to implement table of content extension in Jupyterlab from scratch and have been trying to figure out how we can link certain text in the toc to one specific code/markdown cell in the notebook?
I’d like to click on the linked text and jump to the cell directly.
So far, I’ve been reading through core tokens available (Common Extension Points — JupyterLab 4.0.0a34 documentation) but not sure which one would we use for the purpose mentioned above.
Any help would be appreciated!
Reading the existing core one will likely be required anyway, so that other tools can plug in to the interface.
Thanks! Reading the source code now.
Hi @bollwyvl, I also came across reactflow and now I want to implement table of content but with each toc item being a node in a graph.
I’ve read through the source code of ToC and it seems that it used WidgetTracker to track each ToC’s model.
Would you say that’s possible?
that homepage crashed for me. maybe not the best upstream to which to hitch a horse? more broadly, just about anything canvas-based is a hard accessibility fail unless one is very intentional.
meanwhile: unless it really need The DOM (e.g. to get markdown previews, and jamming that into canvas somehow), working with documents at the model level will be more reliable than the UI itself. this would mean having to do a bunch of half-markdown parsing, as the current heuristic-based one does. The
Notebook in specific offers its
activeCellIndex as an evented property, which provides many fewer opportunities for memory leaks, but this isn’t generally available (e.g. markdown previews).
Thanks for the input! To provide you more context to the extension idea. The current thought is to implement a graph visualization of the notebook using ReactFlow, with nodes being cells or cell outputs and edges being logical dependencies in the notebook pipeline to help people navigate the notebook pipeline better.
I’ve also considered D3.js or other graph visualization libraries and ReactFlow stood out as it’s easy to implement.
In terms of need for DOM for now I don’t think so since each node will all be the same with different names to summarize the cell. I might want to jam the markdown/code/plot preview into some nodes in the future though.
You talked about working with documents at model level vs. UI level. Could you explain the difference or point me to the right documentation so I can look into it more?
stood out as it’s easy to implement
Right, but “only works in chrome” is kind of a bad look.
model level vs. UI level
Once you get a handle on the
NotebookPanel, it has
.content.model, the underlying NotebookModel.
Document widgets will have such a model, but require different techniques: many are
text, where there’s little commonality between them, but then again, they are usually less complex than a full tree, though things like CSV stand out as “simple” files that have complex UI needs.
I see. ToC has an implementation of
TableOfContentModel class as well and I assume that’s built on top of the model class you sent. I’ll look a further look thanks!