Universal adapter to create prosemirror nodeview from modern UI frameworks. - prosekit/prosemirror-adapter

Changes Overview This PR removes flushSync from the React Nodeview renderer which should lead to better performance, less bugs when it comes to dangling Nodeviews still being reconciled by ProseMir...

quinedot: > But unfortunately, precise capturing with `impl_trait_in_assoc_type` doesn't seem to be implemented yet. (Or I don't understand how it works.) I recalled from elsewhere that it does work,[1] so I also poked at this until I figured it out. You can use precise capturing but the errors aren't great. Applying this change fixes that older playground: impl<'a, 'i, N: NodeView + 'i> Selector<'i, N> for TypeSelector<'a> { type Err = N::Err; - type Iter = impl Iterator<Item = Result<N, Self::Err>> + use<N>; + type Iter = impl Iterator<Item = Result<N, N::Err>> + use<N>; Because otherwise you have a impl Iterator<Item = Result<N, <TypeSelector<'a> as Selector<'i, N>>::Err>> // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ which apparently isn't normalized, so it captures all the generics. So you can probably get rid of some TAITs. * * * 1. to at least some degree ↩︎

// Compiler wants NodeView + 'q here but I don't think this is correct. // the NodeView can be droped after use and the selector should continue // to live as long as `query` is still around * `TypeEraser<'i, S>: Selector<N>` requires `<S as Selector<N>>::Iter: 'i` * `TypeSelector<'q>`'s `Iter` is `impl Iterator<..> + use<N, 'q>` * In fact it's a `std::option::IntoIter<Result<N, Self::Err>>` * The `'i` in `TypeEraser<'i, TypeSelector<'q>>` in the body is inferred, but you coerce that to a `dyn ... + 'q`, so `'i: 'q` is required * So `<TypeSelector<'q> as Selector<N>>::Iter: 'q` is required * So `std::option::IntoIter<Result<N, Self::Err>>: 'q` is required * So `N: 'q` is required (Reasoning about how long values are around is often misleading when it comes to borrow checker errors, which are typically about duration of borrows or the properties of types.) * * * The other error can be fixed by declaring `node` first. fn usage() { let mut node; let query = "h1"; let selector = make(query); node = Node { c: vec![], n: "h1".into(), }; selector.select(&mut node); } Playground. * * * I'm not sure if you had any other questions.

Here are the actual traits I used. I wanted a CSS-like syntax for traversing tree-like data structures so I don't have to use nested iterators, especially ones with guarded nodes. `NodeView` is an adapter for any tree-like data structure. `Selector` traverses the tree using the provided adapter. The playground below is the version where I haven't introduced any helper traits yet. Playground

I tried to design a trait that can be implemented for any tree so that I can adapt it to any tree from other crates to perform traversal operations on it. I have come up with something like this // I could make this dyn compatible later pub trait NodeView: Sized { // Some tree may error like fs::read_dir() type Err; type ChildIter<'c>: Iterator<Item = Result<Self, Self::Err>> + 'c where Self: 'c; fn children<'c>(&'c self) -> Result<Self::ChildIter<'c>, Self::Err>; fn parent(&self) -> Result<Option<Self>, Self::Err>; } But I encountered lifetime error: fn dfs_api_test<T: NodeView>(a: T) where T::Err: Debug, T: Debug, { let c = a.children().unwrap(); let mut stack = vec![]; stack.push(c); while let Some(cur) = stack.pop() { for item in cur { let node = item.unwrap(); // Do something with node... println!("We visited a node: {node:?}"); let c = node.children().unwrap(); stack.push(c); } } } error[E0597]: `node` does not live long enough --> tree_ast\src\lib.rs:80:21 | 75 | while let Some(cur) = stack.pop() { | ----- borrow later used here 76 | for item in cur { 77 | let node = item.unwrap(); | ---- binding `node` declared here ... 80 | let c = node.children().unwrap(); | ^^^^ borrowed value does not live long enough 81 | stack.push(c); 82 | } | - `node` dropped here while still borrowed From my understanding, basically it is required that `node` have to be alive as long as `c`. I tried to do something similar with a concrete type: struct Node { value: String, children: Vec<Node>, } struct Descendants<'a> { stack: Vec<std::slice::Iter<'a, Node>>, } impl<'a> Iterator for Descendants<'a> { type Item = &'a Node; fn next(&mut self) -> Option<Self::Item> { while let Some(top_iter) = self.stack.last_mut() { if let Some(node) = top_iter.next() { if !node.children.is_empty() { let c = &node.children; // Important part here let iter = c.iter(); self.stack.push(iter); } return Some(node); } else { self.stack.pop(); } } None } } In this snippet `iter` when expressed using opaque type, it should be `impl Iterator + 'a` // Code from std pub fn iter(&self) -> Iter<'_, T> { Iter::new(self) } However, `self.stack.push(iter);` complies without error. How is it allowed? And in general, what is a good trait definition to generalize any tree-like data structure to traverse them?

> Why `Vec`’s `.iter()` iterator can outlive the lifetime of the reference use to construct it? It can’t. But it can _live as long as_ the lifetime from the reference used to construct it. In particular, in your “concrete type” version, when you have a `&'a Node` and call `node.children.iter()`, that gets you an `Iter<'a, Node>` — the lifetime is _equal_. On the other hand, your `NodeView` trait forces you to _borrow the view again:_ fn children<'c>(&'c self) -> Result<Self::ChildIter<'c>, Self::Err>; This means you have to supply it a `&'c &'a Node` and the child iter only lives for `'c`, which lifetime is only valid as long as the `&'a Node` — not the `Node` — you borrowed continues to exist. That lifetime shortening is why your code doesn’t compile — your trait has given `dfs_api_test` an obligation to keep `node` alive, but you haven’t done that (and can’t do that in a non-recursive implementation). A trait definition without this problem might be: pub trait NodeView: Sized { type Err; type ChildIter: Iterator<Item = Result<Self, Self::Err>>; fn children(self) -> Result<Self::ChildIter, Self::Err>; fn parent(self) -> Result<Option<Self>, Self::Err>; } Note that `self` is taken by value, and no lifetimes appear because the lifetimes are all in the _implementation_ , not the trait.