Implement - Dataset group mapping and switching

[alyhxn]

@todo

#30

• Implement - dataset
  • Experminetation
  • Implementation
  • Debugging
  • @output 📦 dataset_v0.0.1 from comment

[alyhxn]

Tasks - 2025.02.08

• Implement - dataset
  • Experminetation - 5h
  • Implementation - 3h
  • Debugging - 2h
  • Logged tasks - 10min
  • Recored worklog - 10min
  • @output 📦 dataset_v0.0.1

---

Worklog

worklog-253

[serapath]

feedback 2025.02.08

It looks confusing to me.

1. mapping: { 'style.css': 'style.css' } seems like a redundant mapping, but second, it maps a file, not a category or folder. This seems problematic, because if the entire component tree of an app has 10 components, one would expect each component being able to have more than one file per "dataset name". Now style.css is a dataset name that is also a single file. I guess its good that this is possible, but i imagine that more as a "special case" and usually we are dealing with a category that could be a "folder name"
2. the drive has "theme" as a property, which is confusing, because in a drive, there should be only names that have an .extension (.e.g .css or .js) or names that end with a /, like theme/ to indicate it is a folder. A name without an extension and without a slash are probably supposed to be filenames without extension and the content in the example would be the string style.css ...why not though, but again - looks like a "special case"

---

You say: every file will contain a property to indicate which dataset it belongs to.

This seems problematic. I think root folder names of drives should be treated as "dataset names".
That means, every file inside such a folder is part of that dataset name.

That way, if the user provides another external drive with a folder that contain a bunch of files, then choosing that drive to be used as an alternative dataset, our app would just replace all current content of the dataset name folder with the content of that drive.

If that external drive does not contain a specific required file, maybe it will fall back to the "default" one of the component or it will just not provide anything ...which is sometimes fine and sometimes might throw an error. ...the error could be thrown by first checking all files required and whether the new external drive contains replacement files and if it does NOT, then maybe indicate that this external drive cannot be used?

---

Looking at your editor, there is a lot of space on the right.
I think, for some situatoins, it would help a lot if you split the editor in left and right.

1. Then show e.g. the page.js file on the left and explain the fallback and mapping
2. and show e.g. the "app subcomponent" on the right, with its fallback to show what exactly is the effect of what is defined in that drive and how it gets replaced based on the mapping.

That way i could see both at once.

I would even go further, reduce the font size by one tick if needed, but split the editor in 3 or even 4 areas... left top, right top, left bottom, right bottom ....

This could be used to also show the STATE module and the relevant code sections that take care of providing the right data to the right component.
It could also be used to show even a "sub sub" component of "app" to show more than one sub component and how both receive a switched theme from the data provided by the user or a super component.

---

Mapping

The way you explain it is great, but you just explain it for a single file, like.

• how the sub node theme.css will be treated by theme switching as if it was named style.css, but it is a solution for a single file only.

Imagine we have a nimage gallery that shows all images in a folder pictures/
And maybe we prepare an alternative drive or provide a folder with a name images/ and so we want to declare a mapping mapping: { 'pictures/' : 'images/' } so that for the action of dataset switching, the sub nodes 'pictures/' folder is treated as if it was named 'images/'

I imagine that to be much more common than single file dataset names.
But both are probably valid options and for some components, a single file might be enough, so good that this is possible too :-)

BUT one thing is also true, the drive property of a component should not provide dataset switching data. We have fallbacks and overrides to define drives with whatever we need for all the component and subcomponents initially to populate the database.

The switching ONLY exists after that, when the app is already running and a user uses the api (basically by using something like the "theme widget" ...or by opening the browsers developer tool and maybe typing raw javascript into it to call some provided api.dataset.register()`` functions to provide new dataset data and then call maybe api.dataset.switch(name)` to define which "dataset name" it should be applied to across all components.

Of course, before a user does that, there should also be an api api.dataset.list() or something like that, to be able to log in json all the dataset names and all the components and what they currently use and then based on that maybe start defining or preparing an alternative dataset, which can then be provided to override things for all "dataset names"

The entire reason why we do it is, so that we can later display to users a few dataset names and then can switch to alternative datasets for a dataset name ...which changes things across all components in the tree, because the alternative "dataset data" was defined to have changes for every component, but was given a name so a user can easily switch by typing a single "name"

e.g. for "theme" to switch from "light" to "night" or for language to switch from "english" to "french", without the need to know all the different components in the tree and what goes where...

---

In general regarding the idea:

1. each module only defines mappings for their direct dependencies
2. if a module defines an override for a sub dependency, then that override will be used and thus it has to define the direct mappings for that component as well and so on...

Each module has a drive
Each instance also has a drive

So module overrides need to contain mappings for modules
and instance overrides need to contain mappings for instances

If it has a drive, it needs a mapping.

For every component we need to have an easy way to identify all "dataset names"

1. if we dont provide mappings for something, the STATE module needs either throw an error or verify, that the dataset name of the dependency that is not mapped is already the same name as a dataset name in the super component. In that case the "mapping" is unnecessary, because they are already the same. In our example we should include this case as well, but also include cases where they are not the same, so we need to define mappings and also not just for files, but for folders as well.

**Generally, our example and example2 code should try to trigger EVERY POSSIBLE FEATURE the STATE module supports, so we can make sure they all work.

---

structure of drive

Its not that we got theme/language/geolocation/etc...
This is up to the component developers. We as STATE module developers should not need to predefine any of those names. We just provide a way how component or app developers can name and map their dataset names however they want. ...to us it should all be files/folders and "mounting/symlinking" replacement data for those when a user decides to switch datasets.

In general, a dataset name should be nothing else than a file name or folder name or maybe a file/folder path.

In theory, a user using raw admin api's or the theme widget ui, should be able to manually specify changes to any file on any drive of any component in the component tree.
BUT ...if we want to offer easy switching of datasets, we need to offer the user an option in theme widget or raw api ...to switch a dataset for an alternative dataset.

how?
provide a dataset and then use it to replace data in an existing dataset.

A dataset contains data potentially across all components in the component tree, each component developerd potentially by a different developer.... an example of that could be "language".

Maybe like this:

1. dataset.register('theme/', 'night', drive)
2. dataset.switch('theme/', 'night')
3. or also dataset.list('theme/') // => ['light', 'night', 'rainbow', 'default']

The theme/ folder groups things
If the name of the dataset was style.css, then that is possible, but also means every component can only have a single file and not multiple.

BUT Does that even make sense?
The problem is, that we cant really enforce that not some developer of all the components in our app's component tree was using more than one file for their theme, e.g. icons + fonts + 2 css files... but if the dataset name is only a single file like style.css, then how can we map that?

=> so maybe we should enforce that mapping names always have to be folders

• that way developers who only need a single file still can define only a single file inside their dataset name folder, such as style/main.css and we would later map style/ to theme/ and then we know a dataset needs to provide a theme/main.css for that component and the STATE module will translate that provided dataset to style/main.css when loading it for that component... if that makes sense.

Let's discuss questions on discord :-)

---

[alyhxn]

Tasks - 2025.02.15

• Update - dataset_v0.0.1
  • Coming up with the idea - 2h
  • Connecting the dots - 3h
  • Implementation - 3h
  • Logged tasks - 5min
  • Recoreded worklog - 15min
  • @output 📦 dataset_v0.0.2

---

Worklog

worklog-254

[serapath]

feedback 2025.02.15

Looks good, but i couldnt find the "admin api" to actually test listing and providing a different dataset the way we talked about last time. That's still missing?

Otherwise it looks good, but the docs should be improved still, evebn though they are already much better.

This are the latest docs:
https://github.com/playproject-io/playproject-io.github.io/blob/c58c0c713ac9c623fbe95e3c423103e963ee39a9/doc/state/state-usage.md

I was expecting it more to look like:

function fallback_module(){
  const old_dataset_name1 = 'foo'
  const old_dataset_name2 = 'bar'
  const new_dataset_name1 = 'baz'
  const new_dataset_name2 = 'meh'
  return {
    _: {
      "<submodule1>": {
        0: override_function || '',
        1: override_function || '',
        ...
        mapping: {
          [old_dataset_name1]: new_dataset_name1,
          [old_dataset_name2]: new_dataset_name2,
          ...
        }
      }
      "<submodule2>": {
        ...
      }
    },
    drive: {
      '<dataset1>/': {
        file1,
        file2,
        `<folder2>/': {
          ...
        }
        ...
      },
      '<dataset2>/': {
        ...
      }
    }
  }
}

and also the state-usage.md#example at the end is still old and outdated.

I think what would be possible as well is to link to example and/or example2 code in the state-usage.md. You can open the source code for example or example2 on github and click a code line number or shift click a second code line number to highlight specific lines and then copy the url bar address to link directly to the source code with those specific lines highlighted.

Also, not to forget to define everything the fallbacks/overrides support, you mention the _ and drive properties, but we also need the on and api property.
We can maybe - for now - still skip the on property, but at least we need api.

And also when a module exports multiple functions we need to document how to deal with it and/or link to an example and mark the lines as described earlier.

here is btn$small

---

admin api

First, the dataset_api ahould only exist on the first root module's statedb.admin (in addition to STATEMODULE.dataset_api property and nowhere else. Components itself already have access to their drives anyway, so we dont need a "dataset api" for a component to access its own "dataset", because this can already be done by each component interacting with its own drive.

So the dataset api is an admin api for users or components like the "theme_widget", to allow a user to change datasets app wide.

Now the way you implemented it isn't bad, but the direct and indirect mappings at each dependency level should lead to a situatoin where you have a finite set of "dataset names" finally set by the root component developer (or app developer) basically.
Those should be the same for all modules and instances regardless of paths, because of the mapping process. Now of course - maybe we could list the original dataset names for an individual module or instance path, but for now that is out of scope, because i cant see a use case for it.

Second, when looking up the dataset name and path of a specific instance, it should give you the "folder structure" of that drive or an array of paths. ...

The additional information you display now, like: {files, id, mapping, name} seems verbose and not needed. We could consider another api call, someting like .meta() to retrieve additional information about the original dataset name and which component mapped and so on ...basically STATE module internal information, but for the purpose of a designer setting a different theme, they dont need to know so much.

They need to choose a dataset name and know all module/instance paths and the drive paths for that dataset name so they know what files to provide an alternative for.
Then they would use the admin api to provide that alternative content and then call a method to switch a specific dataset name to a different content...

• THINK: .set('theme', 'night') or .set('theme', 'light')

Before that works, somebody would need to create and store a "night" theme, which requires to list all module/instance paths and possible replacement files for what exists ...potentially re-using or patching existing ones... the exact features will need to be adapted as we use them :-)

Basically:
The admin api is a way to test, because for any complex app, for now example and example2, but later playproject and task messenger and others... you can list all the current datasets with their paths for all module and instance drives with their content.

And then also provide alternative inputs for datasets, re-using parts of existing, patching or replacing some or all of the data... for one or multiple datasets.

If we have that API and then we use it to make playproject work and we design different themes and so on, we will learn better how well that "admin api" works and what needs we have to slowly refine and improve the dataset group mapping and switching mechanisms.

The contept we currently have is basic and then we will improve it while using it and get to know how it feels in practice.

So this is slightly confusing and maybe lists too much and unrelated parts.

I expect the "dataset group mapping and switching" admin api to only deal with drives.
So what is shown in the above image as type: '....path....' together with the module/instance name e.g. foot:0 or just 0, that would be like a url "origin", e.g. given the url of this github issue, the origin would be https://github.com, thus the component instance or module path is the "origin" ...and then it is set to its drive object.

The dataset name should be the protocol if it was an url, for example:

• theme://page/app/head/foo/nav/menu/btn/icon:0#style.css
• theme://page/app/head/foo/nav/menu/btn/icon:0#icon.svg
• theme://page/app/head/foo/nav/menu/btn/icon:0#font1.otf
• language://page/app/head/foo/nav/menu/btn/icon:0#en-us.json
  which would be derived from:

// page/app/head/foo/nav/menu/btn/icon:0
const drive = {
  'theme/': {
    'style.css': { /* ... */ },
    'icon.svg': { /* ... */ },
    'font1.otf': { /* ... */ },
  },
  'language/': {
    'en-us.json': { /* ... */ }
  }
}

Now all other components in the tree will also have one of the prefixes language or theme, but of course, their original drive might actually look like

const drive = {
  'style/': {},
  'lang/': {},
}

But the mapping done by the super components direcetly or indirectly mapped it to theme or language in the root component level and if an alternative theme or language is provided, the STATE module will correctly map it to whatever a module has hardcoded as its true dataset names if that makes sense.

Technically, the admin api when listing what exists, could also just return an array of those <dataset_name>://path/to/module/or/instance...#path/without/dataset_name_folder/to/folder.xyz ...if that makes sense.

If a module or instance does not define a drive, it should still have an empty drive ...but for listing it wont show up, because nothing exists to show as a path...

Finally, ...but that was already mentioned in the last feedback i think - the first/root modules statedb function should have a statedb.admin property with the api to list, provide new and switch between datasets :-)

AND ...of course... **document it and/or explain it to ahmed so he can document it and start using it in all components he makes :-)

[alyhxn]

Tasks - 2025.02.20

• Update - dataset_v0.0.2
  • Implemented registration - 3h
  • Implemented switching - 4h
  • Updated docs - 2h
  • Discussion - 5h
  • Processing the feedbacks - 3h
  • Recorded Worklog - 10min
  • @output 📦 dataset_v0.0.3

Worklog

worklog-255

[serapath]

feedback 2025.02.20

Heya, lets jump right in :-)

This is a good idea, if you are the developer of page and use sub components which have their default themes, why not store some themes in the page drive so you could use it to load or register that data and switch themes.

BUT ...of course there is a BUT :-)
This should be just generic data on the drive and there should be no opinions about naming or anything that would make it semantically an alternative theme for another given theme.
This kind of stuff should happen through the admin dataset api

Which you showed is available under STATEMODULE.dataset_api..., but should always also be available to the first root module (e.g. "page"), as a property of statedb.admin, so e.g. statedb.admin.dataset..., such as for example:

const { dataset } = statedb.admin // or STATEMODULE.dataset_api (i guess?)

dataset.show // show currently active dataset
dataset.show() // 'default'
dataset.list // list all dataset names (root level final mappings) with all registered named datasets for each dataset name
await dataset.list() // ['theme', 'lang']
await dataset.list('theme') // ['light', 'night']
await dataset.list('lang') // ['en-us', 'ur-pk']
dataset.register // register a new dataset by title for a dataset name
await dataset.register('theme', 'rainbow', theme_dataset_json)
await dataset.unregister // unregister a new dataset by title for a dataset name
await dataset.unregister('theme', 'light')
dataset.switch // switch the active dataset
await dataset.switch('theme', 'rainbow') // which dataset name to which dataset title
dataset.show() // 'rainbow'
/// MAYBE:
const dataset_json = dataset.get(type, name) // to get the value

UPDATE:

• Please scratch the naming and lets call dataset names things like night/light/rainbow/...
• and call dataset types things like theme/language/...

Basically, every component drives root folder describes "dataset type names" or short "dataset types" and the mapping we do maps those "types", so that we at the root component end up with a usually short set of dataset types for the entire tree of modules/instances.

We can then define a few dataset names for each dataset type and register named datasets and then switch a specific dataset type to a different dataset name... cool?

...maybe that would work?

Now the following should NOT be done:
![bad api](
The "dataset api" should not allow you to interact with a specific component or instance, but instead:

1. you always list globally which gives you all dataset names (only the final mapped names) and then for each dataset name the paths to all (sub)modules/instances/... and then all the file/folder paths for each module/instance... but NOT the file contents :-)
2. to register a new dataset, one would provide an existing dataset name to the register function and then a second param with the name of the dataset we want to register, e.g. statedb.admin.dataset.register('theme', 'rainbow', theme_dataset_json) where the json is basically an object like:

const theme_dataset_json = {
  'page': {}
  'page/app': {}
  'page/app/head/foo/nav:0': {}
  // ... and maybe other modules/instances we want to define...
}

If one wants to literally only patch a specific module or instance and nothing else, the above should just define a single path and ignore all other paths, which would then probably use the default built in values, which means when switching the "dataset" from one custom one to another and most things in both datasets are the same, then we need to duplicate/copy/fork the orginal dataset and modify only the little thing we want to modify.

i would initially NOT start by defining "datasets" which are patches or combinations of other existing "datasets" ...we can wait and see if we need something like that in the future...

For now, to define those on the fly, you could use the "maybe" suggestion above const dataset_json = dataset.get(type, name) // to get the value which would return a structuredClone of that dataset_json, which can then be "patched" and registered under a different name...

This one isnt good, because, as said, there should not be a register function for individual module/instances paths and even if that register call was a global call, then it lacks the definition what type of dataset that new dataset with the name theme:1 is. The type can only be one of the dataset names defined by the app, which should be a very short list usually, because all sub components have been mapped so that in the end the root component has a few dataset names that (in)directly map to all the names any sub components might define. ...kinda the reason we did the "mapping" in the first place.

The path page/app/head/foo:nav would need to be a property of the value that in your example contains the key style.css ... ...but you see my example above :-)

Basically, this should work by using e.g.

const { dataset } = statedb.admin
const subdrive = await sdb.drive.get('theme:1')
await dataset.register('theme', 'theme:1', subdrive)
await dataset.switch('theme', 'theme:1')

Also, every drive: {} property defined in a fallback should have foldernames ending with a /, but theme and theme:1 dont. This should throw for now.

[alyhxn]

Tasks - 2025.02.24

• Update - dataset_v0.0.3
  • Updated dataset.list - 3h
  • Updated dataset.register - 2h
  • Updated dataset.switch - 2h
  • Added dataset.unregister - 1h
  • Added new docs temp.md - 2h
  • Added links to examples in state-usage.md - 5min
  • Debugging (data.api and multiple overrides) - 4h
  • Added the $ prop for module overrides - 4h
  • Logged tasks - 10min
  • Recorded worklog - 20min
  • @output 📦 dataset_v0.0.4

---

Worklog

worklog-256
worklog-256.1

Proposal

• Improve error logging to help new devs understand the mistakes they make. Especial is on the fallback structure
• Make both examples identical except for their obvious difference.

[serapath]

feedback 2025.03.03

The original proposal was the following:

const { dataset } = statedb.admin // or STATEMODULE.dataset_api (i guess?)

// `dataset.show` show currently active dataset
dataset.show() // 'default'
// `dataset.list` list all dataset names (root level final mappings) with all registered named datasets for each dataset name
await dataset.list() // ['theme', 'lang']
await dataset.list('theme') // ['light', 'night']
await dataset.list('lang') // ['en-us', 'ur-pk']
// `dataset.register` register a new dataset by title for a dataset name
await dataset.register('theme', 'rainbow', theme_dataset_json)
await dataset.unregister // unregister a new dataset by title for a dataset name
await dataset.unregister('theme', 'light')
// `dataset.switch` switch the active dataset
await dataset.switch('theme', 'rainbow') // which dataset name to which dataset title
dataset.show() // 'rainbow'
/// MAYBE:
const dataset_json = dataset.get(type, name) // to get the value

0. you mention in the end you are confused about the .get api and .unregister

   • unregister - is supposed to remove a registered entry, like "rainbow" from the .list('theme') return value and it also prevents to switch the the theme to "rainbow" after unregister "rainbow" has been called. unregister will throw an error if the dataset you try to unregister is currently actively in use, so you would first need to activate a different dataset to allow unregistering. This seems the best option to avoid ending up in a state where no datset remains which would leave the app in possibly a broken state, because some components might expect some data and will break if no data at all is provided.
     • ALSO: this allows us to remove default datasets from storage and memory as well, but if we allow unregistering an existing theme and make it fall back to default, then we always need to keep the defaults around just in case, which is worse for memory and disk space. AND it also is a safety mechanism to not by accident remove something that is currently in use (e.g. like deleting a program that you currently run, which might crash things)
   • get - the get method is basically what you added under .list, e.g. .list('theme', 'default'), where "theme" would be the dataset type and "default" or "rainbow" would be dataset names, so that was meant to be used for .get('theme', 'default'), but also like you see below, its supposed to return a drive or some object that represents the entire theme and not a list of theme paths or parts...

1. i think you forgot an "i" in dataset.switch and it just says swtch, which i would either not do, or if you did it to make object destructuring easier, e.g. because switch is also a javascript syntax keyword and we want to avoid writing const { switch: pin } = dataset, maybe we should try some different synonym for the word "switch", e.g. .pin or .use or .pick or .swap or .change or .select or .mode or .focus or activate. This would allow const { pin } = dataset to work?

2. You seem to have merged dataset.list with dataset.get.
   Maybe that is a good idea, but reading the command did not feel intuitive.
   If we merge them, maybe we could rename list to get instead? ...feels more neutral, because .list('theme', 'default') would literally provide me a single "theme drive" or "theme file" and not a list of independent theme parts, but otherwise interesting and probably good choice :-)

---

This is great and definitely somehow what i imagined api wise, but security wise, this is a problem.

Only the root component is meant to have access to .admin, because this is an api that allows to influence every part of the app and a random button component or even a menu component is not meant to have that kind of capability noramlly.

If there are timing issues, then lets talk about it. Maybe we need to make methods async and we have to await or we have to await something before admin becomes available or find ways how we avoid the timing issue, but we cannot make admin available to all components!, that is a pretty severe security violation

---

+1 of the plan to improve the "error logging", but PLEASE, those kind of plans, always list them as a short summary list of tasks under proposal in the worklog comment :-)

---

💯 cool that we now have the .$ :-)

little coding feedback

using .innerHTML is always slow, because it behind the scenes activates the entire Html parser, just to set a an empty string. The much faster and recommended approach to this is to remove the use of .innerHTML = and replace the div.append with div.replaceChildren(...)

[alyhxn]

Tasks - 2025.03.10

• Update - dataset_v0.0.4
  • Implemented feedback - 1h
  • Error logs - 4h
  • Made examples identical - 3h
  • Logged tasks - 5min
  • Recorded Worklog - 15min
  • @output 📦 dataset_v0.0.5

---

Worklog

worklog-257

[serapath]

feedback 2025.03.10

Thanks. Looks good.
Maybe all Error Message of STATE Module should include a link to the STATE module documentation.

Lastly, further improvements to error messages and the state module should closely track every error or problem ahmed runs into - either by fixing the bug in state module, or improving the error message so ahmed can learn how he can fix it - and one thing again, every error message should always include a link to the state module documentation :-)

Regrading instance fallback being defined outside of module fallback - this might be a common error people will run into, so i think this error should be caught and a hint should be given, that the instance fallback or any function that is being called and that is not defined or anything that is actually being used and that is not defined, NEEDS to be defined INSIDE the fallback_module function and it again should include a link to the documentation, ideally directly with a url hash fragment to link to the specific documentation section.

[alyhxn]

Tasks - 2025.03.18

• Update - dataset_v0.0.5
  • Resolving the errors for Ahmed - 4h
  • Tracing errors back and logging - 3h
  • Discussion - 4h
  • Recorded worklog - 10min
  • Logged tasks - 35min
  • @output 📦 data_v0.0.6

---

Worklog

worklog-258

---

Proposals

1. Log error when module cache is not cleared.
2. Make module fallback names match their require names.
3. Admin control in page.js.
4. Resolve fetch issue
5. Improve multiple exports fallback
6. Remove require
7. Update docs
8. Update order and write concise fallbacks.
9. Make every function async, so we have better control over timing.
10. Make STATE async with the GitHub version.
11. There needs to be a mode where we choose to clear localStorage when the modules are edited
12. Improve error logs and add doc links inside them.
13. Rules.md

[serapath]

feedback 2025.03.19
Thanks for this very informative worklog.
I gave feedback on the corresponding discord thread this time.
Lets basically create a RULES.md and start following a process i described on discord.
Lets include those labels/rules of how we do that in the beginning of RULES.md itself.

This will be our living standard or work in progress specification to solve the issues you describe in the worklog.

[alyhxn]

Tasks - 2025.03.31

• Update - dataset_v0.0.6
  • Make module fallback names match their require names - 2h
  • Resolve fetch issue when deploying on github - 3h
  • Improve multiple exports fallback notation - 4h
  • Update order and make fallbacks concise - 20min
  • Debugging - 3h
  • Improve error logs - 1h
  • Logged tasks - 5min
  • Recorded Worklog - 10min
  • @output 📦 dataset_v0.0.7

---

Worklog

worklog-259

---

Proposals

1. Log error when module cache is not cleared.
2. Admin control in root only.
3. Instead of fetch for import verification use some efficient approach.
4. Update docs and add links to error logs.
5. Create rules.md.
6. Log error when an sid is used for wrong sub-node.
7. Remove require/decrease overhead.
8. Make STATE async with the GitHub version.
9. There needs to be a mode where we choose to clear localStorage when the modules are edited.

[serapath]

feedback 2025.04.02

named exports

first impression, i like it, because it has less nesting and seems to work.
IMPORTRANT: when you define those, please always update the docs and/or rules and maybe to keep things concise, a longer explanation can always be added to the markdown docs using <details></detials> tag to collapse/expand additional explanation, but have a good overview too.

So just to wrap my head around it, the idea is:

"<module_name>": {
  $: override_module_fallback, // optional
  0: override_instance_fallback1,
  // ...
  [n]: override_instance_fallbackN,
  `<named_export_name1>$0`: override_named_instance_name1_0,
  `<named_export_name1>$1`: override_named_instance_name1_1,
  `<named_export_name1>$${X}`: override_named_instance_name1_X,
  `<other_named_export_name1>$0`: override_other_named_instance_name1_0,
  `<other_named_export_name1>$1`: override_other_named_instance_name1_1,
  `<other_named_export_name1>$${Y}`: override_other_named_instance_name1_Y,
  mapping: { /* dataset group mappings */ },
}

To me this looks pretty good to be honest and workable. I can't see a problem with it from the top of my head, so lets roll with it, but please let me know if i misunderstood it.

I really like the decision. I think if the above is what you use now or something similar, it seems better than any past proposal we were talking about so far.

[alyhxn]

Tasks - 2025.04.06

• Update - dataset_v0.0.7
  • Clear module cache when different files require the same module - 1h
  • Add admin control in root only and give access to other modules - 1h30min
  • Use an efficient approach to verify import instead of fetch - 2h
  • Update docs and create rules.md - 1h30min
  • Add doc links to error logs - 20min
  • Logged tasks - 5min
  • Recorded worklog - 10min
  • @output 📦 dataset_v0.0.8

---

Worklog

worklog-260

---

Proposals

1. Log error when an sid is used for the wrong sub-node.
2. Remove require/decrease overhead.
3. Make STATE async with the GitHub version
4. There needs to be a mode where we choose to clear localStorage when the modules are edited.
5. Log error if fallback return object has unknown key.