Duplicated code between chipper-startup.js and TextBounds.js

[samreid]

From #764

I said

(12) . What would have to happen in order to factor out the duplicated code between TextBounds.js and chipper-startup.js? Even if we can't easily factor out 100% of the duplicated code, could we factor out 80% of the code into a preload?

@jonathanolson replied:

This seems like a big maintainability issue to factor it out. They are used in very different places, and have different use cases. I prefer mentioning the other usages, and not attempting to factor things out.

[samreid]

After unifying variable names and reordering a method, I'm seeing around 10 lines of code that are duplicated between those files:

I'd at least like to understand what possible solutions for factoring these out, to understand their costs. If we just had a preload with

initializeTextContainerAttributes(svgTextSizeContainer){
        svgTextSizeContainer.setAttribute( 'width', '2' );
        svgTextSizeContainer.setAttribute( 'height', '2' );
        svgTextSizeContainer.setAttribute( 'style', 'visibility: hidden; pointer-events: none; position: absolute; left: -65535px; right: -65535px;' ); // so we don't flash it in a visible way to the user
}
initializeTextSizeElementAttributes(svgTextSizeElement){
        svgTextSizeElement.appendChild( document.createTextNode( '' ) );
        svgTextSizeElement.setAttribute( 'dominant-baseline', 'alphabetic' ); // to match Canvas right now
        svgTextSizeElement.setAttribute( 'text-rendering', 'geometricPrecision' );
        svgTextSizeElement.setAttributeNS( 'http://www.w3.org/XML/1998/namespace', 'xml:space', 'preserve' );
}

It would guarantee that we are using consistent methods for creating the elements and getting their size.
Would that be more trouble than it is worth?

[jonathanolson]

If we just had a preload with

It would mean we'd need to modify our build process to include preloads into standalone builds (e.g. Scenery). Additionally, it means we'd need to go through EVERYWHERE that loads Scenery in require.js mode, and add the preload as an additional dependency. This seems like a lot of work for 10 lines (including the maintenance of having a preload just for sharing that much code). Further, it seems like the shared code could get refactored somewhat independently.

Would that be more trouble than it is worth?

It's my fairly strong opinion that it's more trouble.

[samreid]

At yesterday's dev meeting, we discussed patterns for identifying and referencing code duplicates or code that should be maintained together. @jonathanolson can you please apply that pattern to this work as you see fit?

UPDATE: Perhaps unifying the implementation (like matching variable names) would be a good step as part of this.