Sounds good!
I took a small step into the codebase last night by trying to get the simplest example in the docs working in my app’s react-styleguidist component library.
Copy-pastying the example code basically worked. Here’s a gist of the little editor component I was playing around with (it should be possible to put package.json in root and everything else in src then hit yarn; yarn run styles to get it to run locally).
One area I had to puzzle through was how to properly initialize the <RenderTree /> json viewer. I initially copied-and-pasted the output of the RenderTree component as json back into my source code so I could initialize the editor with more content. However, RenderTree didn’t know how to interpret bold or italic marks that the stock remirror editor generated. I eventually figured out how to pass in a modifed markMap. I didn’t try to hard to read all the documentation since I assumed it was in flux, so I may have missed the details about that. otherwise that info would be good to add to the docs.
I’d be happy to help with that.
Then I got stuck - I want to add a way for the user to to toggle the <EditorLayout> and/or <RenderTree> between menubar edit mode & direct markdown entry mode, a la https://prosemirror.net/examples/markdown/.
As a first step I just wanted to show/hide various components by triple-clicking the RenderTree or executing a special keystroke.
I saw that there are type definitions for prosemirror config props to do that sort of thing in
remirror/support/types/prosemirror-view/index.d.ts#L406, but I couldn’t figure out where or how to pass in props to <RenderTree> - could you give me a hint or two?
// remirror/blob/master/support/types/prosemirror-view/index.d.ts#L406
/**
* Props are configuration values that can be passed to an editor view
* or included in a plugin. This interface lists the supported props.
*
* The various event-handling functions may all return `true` to
* indicate that they handled the given event. The view will then take
* care to call `preventDefault` on the event, except with
* `handleDOMEvents`, where the handler itself is responsible for that.
*
* How a prop is resolved depends on the prop. Handler functions are
* called one at a time, starting with the base props and then
* searching through the plugins (in order of appearance) until one of
* them returns true. For some props, the first plugin that yields a
* value gets precedence.
*/
export interface EditorProps<S extends Schema = any> {
/**
* Can be an object mapping DOM event type names to functions that
* handle them. Such functions will be called before any handling
* ProseMirror does of events fired on the editable DOM element.
* Contrary to the other event handling props, when returning true
* from such a function, you are responsible for calling
* `preventDefault` yourself (or not, if you want to allow the
* default behavior).
*/
// skipping down a few lines...
/**
* Called when the editor is triple-clicked, after `handleTripleClickOn`.
*/
handleTripleClick?: ((view: EditorView<S>, pos: number, event: MouseEvent) => boolean) | null;
p.s. happy to move this convo over to your repo moving forward, just let me know.