Open alyhxn opened 2 weeks ago
2024.10.18
STATE_v0.0.1
4h
15h
2h
5min
10min
@output
:package: STATE_v0.0.22024.10.24
STATE_v0.0.2
1h
3h
5h
2h
3h
5min
10min
@output
:package: STATE_v0.0.3@output
:package: Fallback_docsfeedback 2024.10.24
for worklog 238 and 239
First, I feel the worklog video is missing a lot of things.
DB
and you posted worklog238 on that issue toodoc/...
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
+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:
snapshot.json
file to downloadsnapshot.json
fileThere 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.
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".
@todo
19
STATE
DB
@output
:question:STATE_v0.0.?