Create - STATE

[alyhxn]

@todo

19

---

• [ ] Create - STATE
  • [x] Implement base
  • [x] Integrate into components
  • [x] Providing secure data to components
  • [x] Listen for changes and trigger relevant response
  • [x] Store and access all data from DB
  • [ ] Improvements to better support data operations
  • [ ] Finalize
  • @output :question: STATE_v0.0.?
    • next #21

[alyhxn]

Tasks - 2024.10.18

• Update - STATE_v0.0.1
  • Implement the fallback management - 4h
  • Planning and discussions - 15h
  • Debugging - 2h
  • Logged tasks - 5min
  • Recoreded Worklog - 10min
  • @output :package: STATE_v0.0.2

---

Worklog

worklog-238

[alyhxn]

Tasks - 2024.10.24

• Update - STATE_v0.0.2
  • Updated fallback data structure - 1h
  • Changes due to change in data structure - 3h
  • Planning and discussion - 5h
  • Implementing level-1 override - 2h
  • Authored docs for fallbacks - 3h
  • Logged tasks - 5min
  • Recorded Worklog - 10min
  • @output :package: STATE_v0.0.3
  • @output :package: Fallback_docs

---

Worklog

worklog-239

[serapath]

feedback 2024.10.24

for worklog 238 and 239

First, I feel the worklog video is missing a lot of things.

1. It does not have a section about DB and you posted worklog238 on that issue too
2. It does not have a section about parser and you posted worklog238 there too (#19 and #31)
3. It does not have a section to walk through the doc/... updates, but fallback docs are linked as an output.

I would be happy if you could structure future worklogs to cover all the outputs and changes you worked on. Either one after another, or if it doesnt fit into 5 minutes, then multiple worklog videos.

Having said that, here my FEEDBACK: :smiley_cat:

STATE.js

STATE.js should not require a hard coded snapshot.json file

status.module_index = {}
status.fallback_handlers = {}

graph_explorer

+1 for highlight color for currently focused entry +1 for color highlighting duplicate names, it is a bit much though

• could we just give duplicates a "pale grey font color"?
• the original entry should not have any special color
• when any pale grey duplicate is selected, it shows the highlight color for
  • the original entry (shortest path from root to entry)
  • and all its expanded duplicates

+1 for showing state when component instance is selected +1 for showing javascript source code files

snapshot.json

Only in the theme widget, there should be special action buttons to:

• export/dump the entire database into a snapshot.json file to download
• import and populate the database from a user provided snapshot.json file

There needs to be a special admin... method to allow such an operation

require

The require function will be customized by us, but we have to implement it all without that. Basically, once we patch the require function, we wont need to require the STATE module anymore. The lines

const STATE = requuire('STATE')
const statedb = STATE(__filename)

will be automatically prefixed into every module.

Apart from that, the main plan is to get rid of budo, but thats it for now.

fallback

yes, fallback system is really simple in its core idea, but quite challenging and complex to implement for sure.

It is confusing that this fallback is called index. Shouldnt there be a proper module name instead? What is the file required? is it just "."? In that case, let that be the name instead of index.

I agree that idx:1 doesnt tell anything, neither does type:1, but then again, all it takes is scrolling in the same file, because fallback_instance and fallback_module are both part of the same file, so it should be easy to figure out. Also usually, the "default fallback data" does not include hundreds of instances or modules, but even then you can still figure it out. All it needs is a CTRL+F and seach for e.g. 1: and it will probably quickly find the key of the required module entry to say type: '...' and you know.

We could of course add the name of the module, but it makes everything more verbose as well. I'm not convinced it improves anything. I feel unsure about idx though looking at it.

When i see idx, i would assume it is an index into an array or something. I constantly have to remind myself, that this is the "module type" of that specific instance.

This seems fine. A fallback override for a direct sub component makes sense.

Just for the sake and in case we dont have another good example, those topnav entries could be a "button instance", so that we get the chance to try out more complex fallback structures, but maybe we get that with contributors or projects already.

QUESTION: I am watching the files and the video and every time you open e.g. a module.json or instance.json, i need to always think for which module or component is it. If I'm inside a file and I watch the code, the fallback function gives me no insights, apart from e.g. require('module.json'). Now i get it, if the instance of module fallback data is large, maybe we want the ability to have a separate file for it, BUT - if it is as little data as in all your examples, inlining the data makes it so much easier to quickly read what is going on imho.

That fallback is a function and doesn't really care how you structure your code, apart from you having to return the "default data" is clear, so people can be creative how they use it. I think for us having the data inside the code file itself is quicker for now.

Do you agree? And if so, could we try to change it and inline all fallback data and skip external fallback data like "module.json" or "instance.json" for now? :-)

prefix (153) We need that in the localStorage. Think of it as a process tree id. We could technically have an option later to restart the entire app a second time Or to start and modify the app under lets say 154. We could then switch processes between 153 and 154 - both using different database data. In order to be able to play with that, we need all data stored in such a way that it is it's own "process tree".