How to use modified version of VirtualDom.js

Learn
1

There is a certain behavior of Html.Keyed.node that I wanna try and fix up.

I’m hoping a complete Elm compiler recompile is not necessary to do that. Is there a more reasonable approach? Some flag that would allow me to use modified kernel code?

2

This is the way I hack on the core modules:

  1. Set ELM_HOME to a folder local to the project I test on, so that I can modify things in there without messing up other projects.
  2. Copy my changed files into for example $ELM_HOME/0.19.1/packages/elm/virtual-dom/1.0.3/.
  3. Remove $ELM_HOME/0.19.1/packages/elm/virtual-dom/1.0.3/artifacts.dat.
  4. Remove elm-stuff/.
  5. Compile the project. You should now get your changes.

Doing all of that manually gets old very quickly, so I put all of that into a script to make it easier.

Btw, this summer I started working on elm/virtual-dom too – and the biggest thing I’ve got left in my project is Html.Keyed. So I’m curious what things you’d like to improve around keyed!

6 Likes
3

This is awesome. Thank you sir!

It may be even more awesome that you’re already checking VIrtualDom.js

Here’s the behavior I wanna adjust:

  • Given list of keyed elements: [a, b, c]
  • When an element is inserted somewhere like so: [a, a1, b, c]
  • I expect the DOM mutation to be a simple call to insertBefore or after.
  • Instead, a document fragment is inserted after element a, which consists not only a1, but b and c as well.

The reason why this trips me up, is because I’m building an animations mechanism which hooks onto the DOM mutation calls using a web component. In the presented case, b and c, already animated into the view. By reinserting them through the document fragment, their css animation unexpectedly runs again.

What do you think?

Edit: I corrected the provided case in this later comment.

1 Like
4

If you make a patch against elm/virtual-dom and submit it as a PR, it could be picked up by elm-janitor virtual dom fork: GitHub - elm-janitor/virtual-dom: The foundation of HTML and SVG in Elm.

Assuming the patch has no other undesirable side effects, it is likely a worthwhile bug fix to incorporate into the janitor, and sounds like it may even be more performant. I am not really sure why the keyed node code does not already work this way as it seems a logical approach to take, but on the other hand its quite a complex and fiddly thing to get right.

Once added to the janitor patch stack, there is a helpful script (GitHub - elm-janitor/apply-patches: Hacky script to apply the patches of elm-janitor) to install it, which basically automates overwriting the package in $ELM_HOME.

3 Likes
5

Cool, that definitely sounds like something that keyed should do! I’ll keep that in mind when I get back to working on keyed in my project.

6

Lydell, have you documented somewhere your purpose/goals for tinkering with the vdom?

Rupert, thanks, I doubt I’ll be comfortable enough to push to it, but let’s see : )

7

For now, the only place to read about it is the #elm-virtual-dom channel in the Incremental Elm Discord. Once I reach a more stable state, I will write things in more public places.

1 Like
8

No worries. If you do put the code somewhere public, and it works well, I would happily volunteer some time to review it and make a solid PR out of it.

1 Like
9

I need to correct my previous case.

If only a single element is inserted, then the anticipated wrapperEl.insertBefore() is called.

The problem I described earlier happens when more than one element needs to be inserted. Example:

  • Given: [ “1”, “4”, “5”, “6”, “7” ]
  • If we insert “2” and “3”: [ “1”, “2”, “3”, “4”, “5”, “6”, “7” ]
  • Then wrapperEl.appendChild() is called with document fragment of [ “2”, “3”, “4”, “5”, “6”, “7” ]

Additionally, I’m observing that any time that a DOM element is added to a document fragment, the element is being removed from the DOM, causing layout recalculation.

1 Like
10

This may have a big impact on performance—I’ve been working on a pure Elm rich text editor for years, and whatever I do, it becomes horribly slow above 10K characters. It’s of course possible (perhaps likely) that I’m a lousy coder, but the DOM updates that the RTE is doing are precisely the kind that you describe (like inserting a letter in the middle of a text). If you can share your modified virtualdom.js, I’d be happy to check if it makes any difference here.

11

Fortunately for me, as I was digging through to understand the document fragment behavior, I was able to adjust my custom element to adapt to it, covering all my edge cases.

Great news for me, but this means that I’ll be able to push forward without needing to modify the VirtualDom.js

I’m leaving you with my analysis so far.

2 Likes
12

This sounds like an usecase for virtualized list (fake scrollbars, rendering only what the user sees + some safety margins). We needed to do that some years back in GWI when our spreadsheet had 10k+ cells - browsers really don’t like that large DOM trees. Give it less work to do is my suggestion.

13

I have some code here for virtual scrolling a text editor, in case it can help you:

There is a catch though. This is for fixed size font code editor. So I can accurately calculate the Y position of any line of text so calculating what is visible in the scroll window is trivial. For a RTE editor, I assume you may have different font sizes, which makes the virual scroll harder to do.

14

Thanks for making that video! It reinforced my understanding of how Keyed is implemented. Also, I learned something new – right-clicking on a node in the inspector and doing “Break on > subtree modifications” is awesome for debugging, I wish I’d learned that sooner!

1 Like
15

Long time ago I wrote a few lines of code that would patch elm/* packages from forks of those packages.

This approach should work for both fixing bugs in the core packages and for experimenting with the kind of stuff that is restricted to the core packages (operators, effect modules, kernel code).

2 Likes