Skip to content

Integrate - STATE module into ui-components #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
8 tasks done
ddroid opened this issue Mar 10, 2025 · 10 comments
Open
8 tasks done

Integrate - STATE module into ui-components #6

ddroid opened this issue Mar 10, 2025 · 10 comments

Comments

@ddroid
Copy link

ddroid commented Mar 10, 2025

@todo

#1








@ddroid ddroid mentioned this issue Jan 31, 2025
10 tasks
@ddroid
Copy link
Author

ddroid commented Mar 10, 2025

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

Worklog

@ddroid
Copy link
Author

ddroid commented Mar 15, 2025

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

Worklog

@ddroid
Copy link
Author

ddroid commented Mar 20, 2025

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

Worklog

@serapath
Copy link
Member

serapath commented Mar 21, 2025

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
ignore
Thats not gonna happen :-)

@ddroid
Copy link
Author

ddroid commented Mar 22, 2025

Tasks

  • Changing code - 1hr
  • Debugging & Disscussions - 2hr
  • created issue and recorded worklog - 20 min

Worklog

@ddroid
Copy link
Author

ddroid commented Mar 27, 2025

Tasks

  • Testing old code & debugging - 2hr30min
  • Discussion - 1hr
  • created issue and recorded worklog - 40 min
  • fixed the error after ali's help - 20 min

Worklog

@ddroid
Copy link
Author

ddroid commented Mar 30, 2025

Tasks

  • Planning - 1hr30min
  • Coding - 1hr
  • created issue and recorded worklog - 15 min

Worklog

@ddroid
Copy link
Author

ddroid commented Apr 8, 2025

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

Worklog

@serapath
Copy link
Member

serapath commented Apr 9, 2025

feedback 2025.04.09

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

@ddroid
Copy link
Author

ddroid commented Apr 9, 2025

Tasks

Worklog

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants