An important pro of ArchieML is that you can write graphic copy without coding. Potential approaches...
1. Editable text
Inside any component, surround editable copy with editable(). That function would turn any text into a collaborative Prosemirror editor (or something simpler) inside the Y.Map in that graphic's BlockMap.
editable() wouldn't take a default value (that would be too confusing for future readers of the code when the text could be completely different). It should take a key that points to a specific value in the Y.Map. The default content will always be the same, like "Write here". The key could be any string, and it's suggested that it's descriptive. Editing and moving the keys themselves will likely be impossible.
This is great and smooth. But there are some tough things:
It might be hard to tell what is or isn't editable. There could be a special on-hover effect/label for editable text.
Often we might need HTML, like for a <b> or a <span>. Here, we'd have to write… code inside of prose inside of code, and it's all inside of prose. Plus, if we introduce HTML, there would have to be two distinct renderings of the editable text… the code (when editing) and the output of the code (when not in focus).
2. Managing copy in a separate tab.
Inside any component, instantiate a copy object with copy(). That function would provide a panel for each graphic that contained text that would get live-passed (store updates) to the graphic component. Now, you'd probably want both text and other parameters, so this would be like recreating JSON or ArchieML.
This doesn't have to be complex. It could be another tab in the code editor, called Writing. And it doesn't have to be abstracted away — it could just be style to import a new copy.json file or something. But then you pull writers into the code editor.
An important pro of ArchieML is that you can write graphic copy without coding. Potential approaches...
1. Editable text
Inside any component, surround editable copy with editable(). That function would turn any text into a collaborative Prosemirror editor (or something simpler) inside the Y.Map in that graphic's BlockMap.
editable() wouldn't take a default value (that would be too confusing for future readers of the code when the text could be completely different). It should take a key that points to a specific value in the Y.Map. The default content will always be the same, like "Write here". The key could be any string, and it's suggested that it's descriptive. Editing and moving the keys themselves will likely be impossible.
This is great and smooth. But there are some tough things:
<b>
or a<span>
. Here, we'd have to write… code inside of prose inside of code, and it's all inside of prose. Plus, if we introduce HTML, there would have to be two distinct renderings of the editable text… the code (when editing) and the output of the code (when not in focus).2. Managing copy in a separate tab.
Inside any component, instantiate a copy object with copy(). That function would provide a panel for each graphic that contained text that would get live-passed (store updates) to the graphic component. Now, you'd probably want both text and other parameters, so this would be like recreating JSON or ArchieML.
This doesn't have to be complex. It could be another tab in the code editor, called Writing. And it doesn't have to be abstracted away — it could just be style to import a new
copy.json
file or something. But then you pull writers into the code editor.