Styjun

I'd be grateful if someone could provide a working example of a nested array populated and accessible across ES6 module boundaries, that is to say with setter and (especially) getter methods called from a dependent module.

No matter which design pattern I base my attempts on, setter methods work fine but getter methods invoked across module boundaries invariably provoke the following:

TypeError: nested_array[at_whatever_depth] is undefined

I am not convinced of polluting potentially simple principles with complex examples, but here is roughly what I'm trying to do.. I'd be mega content with something simpler that actually works..

Previously, the array was populated in the same scope as the code which used it. What follows was an attempt at 'modularising' it. The code simply readies an imported music font ('glyphs') for display.

This particular example goes back to more or less where I started: a state module approach. (Others tried? The slightly more advanced basket and revealing module, and a lot of variations thereon..).

var music_glyphs_store = (function () 

 var pub = ;

 pub.state = [],

 pub.setGlyphByName = function (glyph_name, horiz_adv_x, path) 
 pub.state.push(glyph_name);
 pub.state[glyph_name] = [];
 pub.state[glyph_name]["glyph_name"] = glyph_name;
 pub.state[glyph_name]["horiz-adv-x"] = horiz_adv_x;
 pub.state[glyph_name]["d"] = path;
 ,

 pub.getGlyphByName = function(glyph_name) 
 return pub.state[glyph_name];
 

 return pub; // expose externally
)();

export music_glyphs_store ;

The problematic call is to music_glyphs_store.getGlyphByName() and its variants. I know that the glyphs I'm trying to retrieve are stored in the array: the dependent module simply can't access them..

Here's what a typical font element might look like in the original, raw, svg file.

<glyph glyph-name="scripts.sforzato" unicode="" horiz-adv-x="219"
d="M-206.864 126.238c-8.498 -2.679 -12.964 -10.131 -12.964 -17.821c0 -6.455 3.146 -13.0777 9.696 -17.1846c1.8 -1.1369 -9.04799 1.8 139.074 -37.9895l103.026 -27.7105l71.6682 -19.279c12.269 -3.31579 22.358 -6.11053 22.358 -6.25263
c0 -0.142105 -10.089 -2.93684 -22.358 -6.25264l-71.6682 -19.2789l-103.026 -27.7105c-154.231 -41.4474 -137.132 -36.7106 -140.4 -38.8895c-5.625 -3.7263 -8.44299 -9.80721 -8.44299 -15.8892c0 -6.056 2.795 -12.113 8.396 -15.848
c3.147 -2.07201 6.077 -3.08401 9.87399 -3.08401c3.061 0 6.685 0.658005 11.442 1.94801l161.053 43.2942c228.488 61.4133 240.486 64.527 240.486 65.2851c0 0.0888996 -0.164993 0.1455 -0.164993 0.26c0 0.0702 0.0619965 0.1623 0.263 0.297099
c5.63699 3.7421 8.45499 9.80522 8.45499 15.8684c0 6.06316 -2.81799 12.1263 -8.45499 15.8684c-3.17401 2.0842 2.27299 0.521 -46.137 13.5474l-194.447 52.2947l-161.053 43.2947c-4.795 1.316 -8.506 1.94601 -11.581 1.94601
c-1.907 0 -3.57001 -0.243004 -5.093 -0.714005z" />

Here's how the calls are set up:

import music_glyphs_store from "./music_glyphs_store.js";
import * as d3 from "d3";

Then (having, at some point, loaded and parsed the raw xml strings from file):

d3.selectAll(note_glyphs.getElementsByTagName("glyph")).each(function(d, i) 

 var glyph_name = this.getAttribute("glyph-name");
 var horiz_adv_x = this.getAttribute("horiz-adv-x");
 var path = this.getAttribute("d");

 music_glyphs_store.setGlyphByName(glyph_name, horiz_adv_x, path);
);

Whatever the purpose, the idea is that stored values can later be recovered using calls to the above methods. For example:

console.log("index.js: Recovering " + music_glyphs_store.getGlyphByName("brace446"));
console.log("index.js: Recovering " + music_glyphs_store.getGlyphByName("accidentals.natural.arrowdown"));
console.log("index.js: Recovering " + music_glyphs_store.getGlyphByName("noteheads.s2slash"));

In deference to the ES6 module conventions, I later tried eliminating the duplicate ('superflous') state module wrapper (goal: better selective exposure of inner variables and functions) - but to no avail. Declaring the array root variable at window (global) scope also brings no improvement.

The motivation for all this is a migration of existing code -with conventional html inclusions- to Webpack with it's module export/import approach, thereby also leveraging node.js's strengths. While breaking a lot of previously working code, I'm optimistic about the long-term benefits..

The problem would seem to lie with the visibility/scope of dynamically allocated memory. I begin to wonder if nested arrays can be used in a diverse Webpack context at all. Am I perhaps barking up a dead tree?

I think you are confusing array and objects. Arrays are sequential lists, where the index of each cell is an integer. Your code is pushing glyph_name and unicode onto the state array, which places it in next element in the array, but then you are referencing the array using glyph_name and unicode as the index. I think you want to be using objects instead of arrays. Change the lines:

pub.state = [];
pub.state[glyph_name] = [];
pub.state[unicode] = [];

to

pub.state = ;
pub.state[glyph_name] = ;
pub.state[unicode] = ;

Though incorrect, I'm leaving this answer in place to illustrate what (as pointed out by @Bergi in the comments) qualifies as "array abuse".

The consistently unsettling thing here was that the original code worked fine. It only broke on integration to Webpack. That suggested that structurally, things may be more or less ok, but that in the earlier implementation, there were likely related problems.

With a little experiment, I found I could successfully retrieve array values across module boundaries by enclosing glyph_name in rounded brackets. For example:

pub.getGlyphByName = function(glyph_name) 
 return pub.state[(glyph_name)];
,

BUT 1) I don't entirely understand what is happening, and 2) it looks fragile..

The actual (external, dependent module) call would remain as in the original question.

--> Immediate problem solved, but only by abusing the arrays..