Create - ActionWizard

[ddroid]

@todo

#1

• create action-wizard
  • @input 📦 from Hackmd Notes
  • @input 📦 from Figma Prototype
  • @input 📦 from Figma Designs
  • @output ❓from ThemeWidget v0.0.1

---

• create menu
  • @input 📦 from ThemeWidget v0.0.1
  • @output 📦 from ThemeWidget v0.0.2

---

• Added selected feature in menu
  • @input 📦 from ThemeWidget v0.0.2
  • @output 📦 from ThemeWidget v0.0.3

---

• Updated according to feedback
  • @input 📦 from ThemeWidget v0.0.3
  • @output 📦 from ThemeWidget v0.0.4

[ddroid]

Tasks

• Updated Notes - 20 min
• Created search-bar.js - 2hr20min
• Created Action-bar.js - 1hr30min
• Created Index.js - 40min
• debugging - 1hr
• research - 40min
• styling in index.js - 2hr
• created issue and recorded worklog 20 min
  • @output 📦 ThemeWidget v0.0.1
  • @output 📦 Webpage

Worklog

• worklog-02

FeedBack

• Have converted to standardJS and snake case.
• simplyfied the components by using template literals.
• Improved readability.

Proposal

• Upgrading search-bar and more styling

[serapath]

feedback 2025.01.20

1. thx, the preview page is now much better https://ddroid.github.io/ui-components/
   • it doesnt include a title for the "action bar" in front or on top of the displayed action bar
   • it does not yet include a menu for me to click and scroll to any of the shown components (currently of course there is only the action bar and placeholder for 3 more components)
     • e.g. using <a href='#${component_name}'>${component_name}</a> anchor tags
   • it does not show sub components standalone, e.g. action-bar/icons and action-bar/search-bar should probably become src/node_modules/icons.js and src/node_modules/search-bar.js and then you can use require('icons') and require('search-bar') instead and thus display icons and serach-bar separately on the preview page
   • it doesnt yet have a box drawn around each component with a way to resize it to allow somebody who views the components to resize and explore the responsiveness. I last time shared a code snippet how to approach that on discord in the worklog-2 thread:

   // web/index.js
      // ...
      const container = document.createElement('div')
      container.style = "border:1px solid black; resize:both; padding: 20px; overflow:auto;"
      container.append(fn())
      return container
      // ...

2. the rest is just mostly what was repeated earlier see discord

[ddroid]

Tasks

• Updated Existing code according to feedback - 20 min
• Created menu in web/index.js - 1hr20min
• Debugging - 15min
• Styling - 20min
• Research - 15min
• created issue and recorded worklog 20 min
  • @output 📦 ThemeWidget v0.0.2
  • @output 📦 Webpage

Worklog

• worklog-03

Proposal

• Adding states to searchbar and updating according to feedback

[serapath]

feedback 2025.24.01

Looks good in many ways. Cool to update the address bar with what component name is selected.

A few things I noticed:

0. other useful modules

like loadsvg and others you found in playproject code base.

Sadly - at the moment, these are not published to npm, but this is also not what we plan in the long run. These are also very small, so you might as well "copy" them and they could become part of e.g. your icon module ...

Once we are ready - which is hopefully soon, we will have a feature to be able to load modules, like loadsvg from the playproject page directly. This will work by loading/embedding an iframe to playproject website into our page and then just listing and downloading modules such as loadsavg from that iframe into our page and cache them in the "localStorage", so we dont need to do it again every time we load the page.

For now we dont have that yet, so in this transition phase we either have to skip using them or we improvise and add a comment to later do it the way i just tried to describe when we have that feature ready :-)

1. event listeners (already mentioned in last feedback)

all event listeners should use element.oneventname = oneventname

2. reset element content

if there is a need, it should always use element.replaceChildren() instead of element.innerHTML = ''

3. class names of elements (already mentioned in last feedback)

as said before, because of the closed shadow we use everywhere, there is no way to select and change an element from the outside.
Thus, it saves lines of code and execution time if we just hard code class names instead of storing them in a variable name just for the class name, which you or we already dont use in the get_theme function, so why bother elsewhere.

4. styles (already mentioned in last feedback)

I still see the <style> tag being used instead of .adoptedStyleSheets
So we do NOT create a style element and set its .textContent, but we create a CSSStyleSHeet and ....basically code snippet was given last time.

Lets go to the previous feedback comment and to the discord feedback discussion of the previous worklogs.

5. in web/index.js

you again could make way more use of template literal instead of manually creating all those elements. First a li element, then span, then input`, etc....
I mean, the menu did not exist yet in the previous feedback, but i already mentioned we should use template literals more instead of assembling all these elements with native calls, because that makes it really harder to quickly read than a snippet of html.

6. menu

the idea is to select the component box that displays the component instance and the component name hopefully. Those are all part of the preview page web/index.js and thus not hidden away inside of a shadow.

When we have many, a visitor might just want to scroll from top to bottom to watch them all.
The menu is interesting, but if we have 100 elements, i am unsure how to quickly navigate/jump to one. The idea was to always jump to a specific one quickly and scroll it into view.

1. Also, unselecting many might take a long time if we have plenty of components
2. Also, the resizing does not work yet

The "resizing" was already mentioned and a css code snippet was given during last feedback**

Now if in addition to jumping and focusing on a component by clicking its name, we can also make use of the "checkbox" to hide or present only specific components in general, that is a neat unplanned feature, but it could be useful, so we can keep that.

7. components (i think it was also mentioned in the last feedback about the menu)

you still dont have the "main components" listed (chat, graph, editor, actionbar), but each of them, for now just the acitonbar, consist of sub components and those should have a separate entry and should be shown as standalone component instances on the main page :-)

The funny thing is, that in your worklog video, you even show how to export the "search bar" component and you then display it on the main component presentation page, which is good, but what about the rest? :-) ...and why isnt it currently showing on the main page? :-)

Additionally: I think it would be great if the box that should be resizable and surroundes every component instance on the preview page, would also contain some sort of label so one would know the name of the actionbar, which is currently not being shown.

[ddroid]

Tasks

• Updated Existing code according to feedback - 25min
• Updated menu => Coding + Research + Debugging - 2hr 45min
• Styling - 1hr 10min
• created issue and recorded worklog 15min
  • @output 📦 ThemeWidget v0.0.3
  • @output 📦 Webpage

Worklog

• worklog-04

Proposal

• Updating the existing Action Bar using new wireframes and then add new features according to the wire frames.

[serapath]

feedback 2025.01.26`

Thank you. Great worklog. Gave all feedback on discord.

[ddroid]

Tasks

• Updated code according to feedback - 1hr 10min
• created issue and task logged - 10min
  • @output 📦 ThemeWidget v0.0.4
  • @output 📦 Webpage

Worklog/Feedback

• create action-wizard
  • Applied shadow dom in web/index.js
  • Utilized template literals inside the create list function
  • Removed spaces from element properties in template literals
  • Added the placeholder for searchbar in action_bar.js
  • Fixed the scroll on selecting so that the entry appears in middle
  • Changed the formatting of template literals

Proposal

• Utilizing the STATE module in the project.

[ddroid]

Tasks

• Discussions - 30min
• Planning - 2hr
• Coding & debugging - 2hr
• Styling - 1hr
• created issue and recorded worklog - 25min
  • @output 📦 Tabs v0.0.1
  • @output 📦 Webpage

Worklog

• worklog-20

[serapath]

feedback 2025.05.01

Hey hey, given how much time things took i'm not super excited about the worklog, but yeah, lets just see if thats maybe part of the warmup phase and lets see how it goes with the new UI/UX wireframes from cypher an the STATE module mostly working.

So alright, here is my feedback:

1. tabs.js

its a short file and should almost take no time to write and the only one you describe and it doesnt even do much and we had basic components in previous worklogs already. It doesn't even use STATE and instead passes things like labels and icon names as regular function params, which is an anti pattern, because that is the entire point why we introduced STATE in the first place.

• 
• 

The only thing that is okay is to pass a callback until ali actually added the io module so we can replace it, but no data should be passed. Pass a sid instead.

2. a little bit about STATE usage

You dont use the STATE module here. You of course initialize it, but you dont really use it the way it is supposed to be used.

Why did we implement it and why do we want to use it?

If somebody builds a new popup dialog component X and uses an existing one, let's say a button module and they hard code the names of the 2 buttons they use, e.g. "OK" and "Cancel" and exports a function with a single paramter "text" AND then if somebody else wants to make another component Y and wants to re-use that component X (the dialog) and passes in a text in spanish, then the buttons should read "Bien" (=OK) and "cancelar" (=cancel), but the component X has no params to pass different button names, because the author of component X only considered the "text" param.

THIS SUCKS!
It is the main reason, why most frontend components cant be re-used, because there is always a dependency that is used in a specific way and you cant change it anymore, so you have to either rewrite component X or hope the author of X updates it or you have to fork component X to maintain your own version.

So STATE is supposed to fix this by allowing an author to intercept and override any arguments/params even deep down in the dependency tree and you by not using it basically just repeat the exact thing we try to solve using STATE :-) ...so this needs to change.

Those arguments should not come from params but from what you load from sdb.drive

3. loading svgs

the error when trying to require svg files is entirely correct.

• require is for javascript modules and not any other content.
• you can only require(...) javascript files or modules
• you cannot require other files, like .css or .svg, etc...
• if you actually WANT to read those files, you have to use fs and then read it, e.g.:

const fs = require('fs')
const data = fs.readFileSync('../../src/node_modules/assets/icons/Vector.svg')

• yes, fetch is the other option to do it, but ideally we use STATE $ref for that.

What are problems of your current approach?

• it loads svgs in weird hard coded ways and the label name is coupled to the import path

So now somebody who wants to provide different names or labels needs to know the internal path you hard coded so they can place it in the correct assets/icon folder to make it work. That is really bad.

• 

How should it work?

svg files should be loaded from sdb.drive and set via default fallbacks or overrides

• one advantage of generating the SVGs inside the JS (just like react and frameworks generate the HTML inside JS), is that you can add placeholder like e.g. height, width and many other variables and set them based on needs.

6. no use of fetch, because future components will probably not have access to the network, only io. There might be a special root function to receive specific io requests to fetch stuff, but components cant fetch directly

• e.g. usually we set file content for drives as { raw: "... file content ..." }
• there is or should be a way for { $ref: 'relative/path/to-file-content.svg' }
  • might not be implemented completely, but if you use the $ref version, you are supposed to
  • be able to get the content of that file stored in the sdb drive, if it comes from the components repository, e.g. /src/node_modules/tabs/index.js + /src/node_modules/tabs/svgs/icon1.svg, etc...

4. tabs bar scrolling

there is a scrolling via scroll wheel it was supposed to be a scroll via SWIPE gesture or mouse drag, not scrollwheel, so that needs to be fixed.

Also, it needs to indicate that things are scrollable via scrollbar (similar or the same as vscode shows scrolling when many tabs are open imho.

5. tab

the tab content is meant to have 2 areas:

• the tab label (=everything after the :)
• the tab icon and number (=everything before the :)

6. tabs bar

you asked how the tabsbar should be structured

• 

Now the functionality has the scrollable tabs and the first "pinned" tab (=wizard hat), which always stays no matter how you scroll. The "taskmanager" button and the "docs" button also always stay. How you structure that is up to you.

To me it feels like it makes sense to have all of them as part of the tabs bar, but if you find a different way of structuring it more intuitive, you can do that too and share in the worklog video how you did it. The goal is to achieve the UX described by cypher in his wireframes :-)

7. worklog changes for the future

1. Apart from trying to stick more to the way how we want to build components, lets talk and discuss first, so you can avoid spending a lot of time on stuff that has little impact. This worklog was many hours, including for styling and i can't really see where that went.
   You dont explain anything about styling in the video, yet it took a significant part of the overall work and the tabs bar component file is small and doesnt even have much css and the styling generic and for now the point is to focus on the UX and make things work. Somebody else can later fine tune the styling. So please lets discuss first to avoid spending so much time on supposedly easy stuff.

2. I think it would be good to always add a PROPOSAL section to all your worklogs and list the tasks you plan to work on next.

3. every worklog should from now on always come with 2 worklog videos - it's okay if they are sometimes super short. Nobody cries if you have 2 worklog videos, each 30-60 seconds :-) ...if there is more to show, make them longer - ideally not more than 5 minutes. If a video needs to be longer than 5 minutes because there are many things to talk about, then make an additional video please.