Possibility for a more broken-out build driven by external configuration?

[amb26]

The current build configuration is excellent for producing a very high-performance app with minimal load-time dependencies, but it would be quite helpful for our integration purposes building scrollytelling apps such as https://imerss.github.io/howe-sound-mapping/R-Markdown-AHSBR_Map_1-Reknitted.html# if @imerss/inat-components included in its npm dist a partially built distribution that accepted an external configuration file such as the one at https://github.com/IMERSS/inat-components/blob/main/apps/standalone/src/inat.config.json rather than this being baked into the bundle.

In the end we are aiming for an authoring pipeline that can be driven directly by editing R markdown files and scripts like the ones at https://github.com/IMERSS/howe-sound-mapping/blob/main/scripts/Vascular_plant_map_script.R and whilst we could build the react-scripts process into this pipeline it would be helpful and more performant if we could pull in a "ready to go" configuration-driven distribution of the components - ideally this would also expose configuration of some of the strings seen in the root component definition at https://github.com/IMERSS/inat-components/blob/main/apps/standalone/src/index.tsx#L27

Cheers for any suggestions on the best route for this!

[benkeen]

Hey @amb26, great idea. The first version of this app was very much to satisfy my own requirements for BC Leps, but separating the config from the build files and generally make it easier to consume without having to do any local builds would be great.

Lots to think about here... but how about something like this.

1. In the @imerss/inat-components package, I could include a new standalone.min.js file. That would NOT be referenced in the main/module property of the package's package.json file, it would simply be an extra file that's included in the bundle for anyone that wanted to use it.

2. As a consumer, you could then do this.

<script src="./standalone.min.js" />
<script>
var myData = { 
   // data structure TBH, but this would include everything - settings, classes, strings, etc. 
   // just not the actual data for the app - that would still be external.
};
<script>
</script>
<div class="inat-components" data-source="myData" />

Details:

• First you'd include the new standalone.min.js file
• You'd define all your settings in your own variable somewhere, calling it whatever you wanted
• You provide a custom div somewhere with the class name inat-components (or something a little more scoped... but perhaps this is ok). Then to link the two: the DOM node of where it'll be rendered and the data used as the data source,
• if you provided class names for the elements, you would need to define your own CSS somewhere in the page.

Feels a bit klutzy feeding in the data this way, but alternatives like passing in the data as a serialized HTML property in a data-role strikes me as a pain for the consumer. I don't much like the need for a global JS var, but not sure if there's a more practical way for simpler cases like this. Regular app developers would just use the actual react components and have no need for this whole approach.

Any better ideas? And do you think this would solve your use-case? I could definitely re-work BC Leps to pass the info in this manner instead, so I could then doctor the standalone example in the repo to demonstrate this approach instead.

[amb26]

Cheers Ben, standalone.min.js plan looks just great!

Another possibility is to expose a constructor function accepting the material listed as argument - this has the advantage of being able to bind more easily to a DOM element that doesn't exist at the point the script is loaded. Given we have a configuration-driven system for the scrollytelling interface, we don't actually know in advance where (or even how many!) the inat-component widget is to be dumped, so I had to pull some shenanigans of dynamically loading the script element for it once this was known.

What we do in our in-house integration framework, Infusion, is to expose a standard signature (container, options) to these constructors where container is a string holding a free selector which is expected to hit a single node in the document at the time of execution, and "options" holds all other configuration which, e.g. would be in your "myData" structure. Or our slightly more modern signature where "container" is just another member of "myData".

Of course the ultimate heresy would be to actually return some kind of INSTANCE from the constructor function which I know cuts against the grain of a lot of modern thinking :)

[benkeen]

Yeah, better! If it has to be a globally defined, I prefer that to what I suggested before. So how about this:

<script src="./standalone.min.js" />
<script>
inatComponents.init({ ... });
</script>

I'll expose a global window.inatComponents object which contains an init function. At this point, all we need is that one function but I figure I'll make it an object just in case down the road we may want to expose an .update() or whatever & not break the interface.

I'm game if you are. :)

[amb26]

I'm game if you are. :)

Yup that sounds fantastic!
As we might indeed want more/more varied functions perhaps you could save the top-level object as a kind of namespace and so name the constructor after the profile, e.g. iNatComponents.makeStandalone or iNatComponents.initStandalone or so.

[benkeen]

Agreed, iNatComponents.initStandalone is probably clear. Will do!