Integrate - STATE module into ui-components

[ddroid]

@todo

#1

• Utilize STATE module into ui-components
  • @input 📦 from Discord Feedback
  • @input 📦 from ThemeWidget v0.0.4
  • @output 📦 from ThemeWidget v0.0.5

---

• Test the boot.js
  • @input 📦 from ThemeWidget v0.0.5
  • @output 📦 from ThemeWidget v0.0.6

---

• Fixed the errors
  • @input 📦 from ThemeWidget v0.0.6
  • @output 📦 from ThemeWidget v0.0.7

---

• Moved Files according to feedback
  • @input 📦 from ThemeWidget v0.0.7
  • @output 📦 from ThemeWidget v0.0.8

---

• Tested ali's latest commit
  • @input 📦 from ThemeWidget v0.0.8
  • @output 📦 from ThemeWidget v0.0.9

---

• Initial version of the new menu idea
  • @input 📦 from ThemeWidget v0.0.9
  • @output 📦 from ThemeWidget v0.0.10

---

• Facing new errors or bugs
  • @input 📦 from ThemeWidget v0.0.10
  • @output 📦 from ThemeWidget v0.0.11

---

• Debugged the errors
  • @intput 📦 from ThemeWidget v0.0.11
  • @output 📦 from ThemeWidget v0.0.12

[ddroid]

Tasks

• Updated Actionbar & Searchbar - 1hr30 min
• Testing errors in playproject by changing example 3 - 1hr10min
• Debugging & updating code - 1hr
• Discussions in discord and recorded 2 videos - 50min
• created issue and recorded worklog - 20 min
  • @output 📦 ThemeWidget v0.0.5
  • @output 📦 Webpage
  • @output 📦 Vid 1
  • @output 📦 Vid 2

Worklog

• worklog-10

[ddroid]

Tasks

• Playing around with code - 50min
• Testing boot.js by replacing the files with example3 - 1hr30 min
• Discussions - 1hr10min
• created issue and recorded worklog - 20 min
  • @output 📦 ThemeWidget v0.0.6
  • @output 📦 Webpage

Worklog

• worklog-11

[ddroid]

Tasks

• Implemented STATE in other modules - 1hr50min
• Debugging - 2hr30 min
• Discussions - 1hr
• Got at call with @alyhxn - 20min
• created issue and recorded worklog - 20 min
  • @output 📦 ThemeWidget v0.0.7
  • @output 📦 Webpage

Worklog

• worklog-12

[serapath]

feedback 2025.03.21

As i explained on discord already, there needs to be a clear separation between

1. code meant to be installed/required by other developers in their projects
2. code use to showcase/example/demo/test

web/index.js is meant for showcasing the components

• it is okay to create web/node_modules/* if you need helper modules for the showcasing which arent meant to become modules that are part of what ui-components repository is meant to export
  src/index.js is meant for implementing the components
• it has src/node_modules/... for all internal helper modules used to implement the ui-component repository with its exports for other developers to install and require

It is possible to move some parts of web/index.js into src/..., if they become component modules themselves, such as a "table of content preview menu"-component.

But a menu that hardcodes all modules that exist otherwise in .src/node_modules is way to specialized and will never be re-used anywhere and thus should not become a component.

I shared already a code snippet on discord how to deal with this instead.

---

1. there is the ui-modules repository, which somebody is supposed to npm install as a dependency
2. there is a ui-components preview page, which is such an app tbat requires the ui-components and showcases them

that preview page is not part of ui-components and a user of the ui-components module that contains many components should not "require" the preview page.

so that is why the convention is

1. all the code for the modules goes into /src/...
2. all code for testing or demo/examples of how to use that code goes into /web/...

so if those files would not be merged all into /src/..., that would be great.

also

....the preview page can have or use a table of content preview menu, which maybe somebody wants to use in their own ui-components page with different modules.

so that preview menu can be a component inside ./src/node_modules/..

but then ./web/index.js would need to require it and then require other modules and then ideally only pass an array of names of those modules to an instance of "preview menu" and maybe pass a callback as well until we have the "io" module, so /web/index.js can listen to that callback which triggers every time the preview menu is clicked... which /web/index.js can then respond to my showing or adding or removing etc... an instance of that corresponding module name :slight_smile:

// web/index.js
const ... = require(...)
const ... = require(...)
const ... = require(...)
//...

const sdb = statedb(() => ({
  drive: {
    "names.json": [ // component names
      "actionbar",
      // ...
    ]
  }
})
const element = menu(sid, msg => {
  const { type, data } = msg
  console.log(type, data)
  // e.g. type = 'select'
  // e.g. data = '<component-name>'
  // maybe "actionbar"
})
// ...

---

icon.js error

This is a big deal, because in the future, defining a sub module or instance in the module fallback is asking for permissions to be allowed to do so. This means, if a module is gets require(name)d and wasnt defined in the fallback, then that call will throw an error with the message "permission denied".

We dont throw yet, because we are still using budo and browserify, but we will do this soon, so if the icons module should be requireable, then it should be listed.

For all npm modules which dont use the STATE module, there will be automatic code insertion at the beginning of those files when they get loaded to generate a default fallback, which lists all dependencies in the fallback that are listed as package.json#dependencies.

If you fix this, you dont have to edit icons.js module, because a module is not required to use the STATE module, but if it does, then it should list all.
The behavior for modules that do not use the STATE Module but have dependency is, that they should work, because later they will have the autogenerated one and we simulate that by not throwing.
...if that makes sense.

When we move away from build tools like browserify/budo in the future, we will introduce runtime "loaders", which will replace what build tools like webpack, vite, browserify, etc... do now. There will be a special loader for all modules that come from npm and those will generate the statedb call code snippet that gets prefixed and includes all the sub modules in the fallback that are listed in the modules package.json file.

So we will definitely solve this without any new properties like an "ignore" proprety

Thats not gonna happen :-)

[ddroid]

Tasks

• Changing code - 1hr
• Debugging & Disscussions - 2hr
• created issue and recorded worklog - 20 min
  • @output 📦 ThemeWidget v0.0.8
  • @output 📦 Webpage

Worklog

• worklog-13

[ddroid]

Tasks

• Testing old code & debugging - 2hr30min
• Discussion - 1hr
• created issue and recorded worklog - 40 min
• fixed the error after ali's help - 20 min
  • @output 📦 ThemeWidget v0.0.9
  • @output 📦 Webpage

Worklog

• worklog-14

[ddroid]

Tasks

• Planning - 1hr30min
• Coding - 1hr
• created issue and recorded worklog - 15 min
  • @output 📦 ThemeWidget v0.0.10
  • @output 📦 Webpage

Worklog

• worklog-15

[ddroid]

Tasks

• Discussions - 1hr15min
• Planning - 40min
• Coding events emiting way - 1hr30min
• Split page.js into two parts and added communication between them in the old commit - 2hr
• Integrated STATE module into those 2 modules - 1hr
• Debugging - 1hr
• Created worklog and issue - 30min
  • @output 📦 ThemeWidget v0.0.11
  • @output 📦 Webpage

Worklog

• worklog-16

[serapath]

feedback 2025.04.09

The updates look great :-)
rest of the feedback was given on discord

[ddroid]

Tasks

• Discussion - 1hr25min
• Debugging - 40min
• Created worklog and issue - 15min
  • @output 📦 ThemeWidget v0.0.12
  • @output 📦 Webpage

Worklog

• worklog-17