Alternate diff to #166, but with a bit more micro-optimizations and cleanups after
Status quo, constructing a HTML fragment builds up a big list of Modifiers, which is then taken apart to build a Builder object, which is then taken apart to fill a StringBuilder
After this diff, constructing a HTML fragment builds up a Builder object, which is then taken apart to fill a StringBuilder
As is the case in #166, this makes Frags and Tags no longer immutable. They never really were, especially in JsDom land where they could contain arbitrary mutable DOM elements, but in "most" cases you would be fine saving a Tag in a val and re-using it over and over, possibly adding different sets of attributes or children to it. With this diff, you should no longer assign Frags or Tags to vals, as any children or attributes added will mutate the object and affect all over references to it. All Frags and Tags should be defs and re-computed each time they are needed.
Alternate diff to #166, but with a bit more micro-optimizations and cleanups after
Status quo, constructing a HTML fragment builds up a big list of Modifiers, which is then taken apart to build a Builder object, which is then taken apart to fill a StringBuilder
After this diff, constructing a HTML fragment builds up a Builder object, which is then taken apart to fill a StringBuilder
As is the case in #166, this makes
Frags andTags no longer immutable. They never really were, especially in JsDom land where they could contain arbitrary mutable DOM elements, but in "most" cases you would be fine saving aTagin avaland re-using it over and over, possibly adding different sets of attributes or children to it. With this diff, you should no longer assign Frags or Tags tovals, as any children or attributes added will mutate the object and affect all over references to it. AllFrags andTags should bedefs and re-computed each time they are needed.My rudimentary benchmarks using
Appears to show about: