"in app" editing app

[janfjohannes]

the idea to have "in app editing" or at least a simple way to get from the rendered view of a message to the place where it can be edited (similar to clicking on a component with svelte dev tools) came up multiple times. this discussion will keep track of current limitations and possibilities.

mini-hackathon outcome:

i investigated 3 possible ways to connect the dom nodes for attaching the edit ui to the source of messages.
a) using build-metadata: would work only for specific build tools (vite/esbuild), is limited to showing connections by file eg. component "a" uses message "b" and "c" but not where exactly the message is rendered. this seeems too limiting to investigate further unless all other options fail for some reason.

b) using runtime magic to get information about the rendering context of a message: this seems not possible for pure functions with modern js/ strict mode. when using svelte stores instead of functions, it would be possible to get a connection of each component to which messages are used there. the same limitations as option "a" apply.

c) in the end all messages are rendered to text nodes, therefore the only left option to really associate specific nodes with metadata is by annotating the rendered text with message id and possibly source file information in the text output. in the final poc the format <magicstring>__<messageId>__<magicstring> was used as it allows simple parsing and debugging.

the poc used a mutation observer to look for added dom nodes, scan for the magicstring, remove it from the rendered output and move the metadata annotation to a data attribute of the parent node, so that the ui can attach to this. this worked well but proved to be limiting on the dev experience when not using this feature, as the impact on normal development would be too great (performance impact, flashes of magicstring if it is not removed fast enough etc.), the only viable solution for a next iteration would be to use a hotkey or a toggle switch to enable this behaviour selectively instead of always while in dev mode, similar to svelte dev tools. this would reqire paraglide to not use a devtool flag on startup time but be able to add runtime context to the message render functions that was previously compiled with the message id in scope. This would allwo it to add the magicstring and metadata just in a specific message function execution.

another limitation is the use of html tags in messages and the connected use of "{@html" in svelte, to support these constructs, the text annotation is not required/possible but has to be done directly in the message render function, which also requires to add some wrapper divs or spans to be able to attach the ui to the right entities and not just parts of the html messages.

steps for a viable solution based on current learnings would be:

• add metadata context to compiled message functions in dev mode
• add runtime context to the message render ( if the hotkey is pressed or the edit button is toggled)
• trigger a rerender similar to the switch of a language on toggeling the edit ui display/ hotkey
• render magic string and metadata annotation in pure text messages and data nodes in html messages
• move all text annotations to data attributes while rerendering, some modern js apis such as view transition could probably be used to avoid all short flashes of magic strings in the ui, especially since we have the paraglide provider component which has some control over render of its children
• attach ui to the annotated dom nodes
• when clicking we can use the same method as svelte dev tools to open the right file in vscode or open the right place in fink
• when editing it would be best to try sending a message to the sdk running in the paraglide vite plugin to trigger a message update and use the exisiting sdk update behaviour as well as local state of the dev project

code snippets from poc:

mutation observer

addEventListener("DOMContentLoaded", (event) => {
			const targetNode = document.getElementsByTagName('body')

			const callback = (mutationList, observer) => {
        for (const mutation of mutationList) {

          let nodeIterator = document.createNodeIterator(
            mutation.target,
            NodeFilter.SHOW_ELEMENT,
          (node) => {
            console.log(node)
            return ( node.nodeName.toLowerCase() !== 'script' && node.textContent.endsWith('__pgm')
              && ( node.nodeType === Node.TEXT_NODE || node.children.length === 0)  )
              ? NodeFilter.FILTER_ACCEPT : NodeFilter.FILTER_REJECT
          }
          )
          
          let currentNode
          while (currentNode = nodeIterator.nextNode()) {
            const parts = currentNode.textContent?.split('pgm__')
            currentNode.textContent = parts[0]
            currentNode.dataset.paraglide = 'Message: ' + parts[1].replace('__pgm', '')
          }
        }
			}

			const observer = new MutationObserver(callback)
			observer.observe(targetNode[0], {
        attributes: false,
        childList: true,
        subtree: true
      })
})

edit ui:

	:global([data-paraglide]) {
		-webkit-user-modify: read-write-plaintext-only;
		border-radius: 6px;
		cursor: text;
	}

	:global([data-paraglide]) {
		box-shadow: 0px 0 4px blue;
	}

	:global([data-paraglide]:hover:before) {
		content: attr(data-paraglide);
		border: 1px solid grey;
		border-radius: 4px;
		font-weight: bold;
		position: fixed;
		font-size: 14px!important;
		top: 60px;
		left: 60px;
		padding: 4px;
		color: black;
		text-transform: none;
	}

[LorisSigrist]

Nice exploration & really good ideas!

It seems like returning "magic" strings from the message-render function is the most viable approach. Unfortunately, we are likely going to run into reactivity challenges when trying to toggle between magic-strings and regular text message rendering. Might it be possible to use invisible characters (zero width space & co) to encode the message ID in a text node? This would side-step any flickering issues caused by the magic-string replacement.

Edit: Just checked, and we can put Zero-width spaces into messages without {@html}

[janfjohannes]

@LorisSigrist good idea if we cannot solve the rendering, but im still optimistic its possible

[LorisSigrist]

Just stumbled on this:
https://www.npmjs.com/package/@vercel/stega

Seems like Vercel is using my exact zero-width-space hack to make their Visual Editing feature work :)

[samuelstroschein]

I suggest not shipping such functionality in Paraglide but launching a dedicated app.

• editing messages directly on the site is beneficial to everyone in the inlang ecosystem, not only paraglide users
• shipping this as part of Parglide js goes against our "one app, one use case" philosophy
  -- Communicating an app that does one thing well is easier than a Frankenstein "everything" app
  -- every app itself is leaner and therefore easier to maintain

[jannesblobel]

We have decided not to launch another app as it requires too much effort. ?

[samuelstroschein]

*I suggest IF SUCH FEATURE IS BUILD, to develop it as a dedicated app

I don't propose to build this app. I propose that such a feature should be build as a dedicated app