Create - STATE #30
Comments
Tasks -
|
Tasks -
|
|
feedback for worklog 238 and 239 First, I feel the worklog video is missing a lot of things.
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: 😺
|
Tasks -
|
Tasks -
|
Tasks -
|
|
feedback Lets compare our current and potentially new approach 1// ----------------------------------------------------------------------------
// 1. make icon set its default fallback (=`FB_II`) using the `image.svg` in the above snippet
// icon.js
/***********
NOW:
***********/
function FB_II () {
return { 'image.svg': `<svg>▶️</svg>` }
}
/***********
vs. NEW:
***********/
function FB_II () {
return { 'image.svg': `<svg>▶️</svg>` }
}This is the same, no changes. 2// ----------------------------------------------------------------------------
// 3. make button override icon `image.svg`
// 2. set button default fallback (=`FB_IB1` + `FB_IB2`) to `label/size`
// btn.js
/***********
NOW:
***********/
function FB_IB () {
return {
0: { subs: [1], data: { label: 'button', size: 'small' } },
1: { type: 'icon', override: [override_icon] }
}
}
function override_icon (data) {
data[0].data['image.svg'] = `<svg>🧸</svg>`
return data
}
/***********
vs. NEW:
***********/
function FB_IB1 () {
return {
_: { icon: { 0: override } }, // icon === 'icon:0'
'data.json': { label: 'button', size: 'large' }
}
}
function FB_IB2 () {
return {
_: { icon: { 0: override } }, // icon === 'icon:0'
'data.json': { label: 'button', size: 'small' }
}
}
function override (data) {
data['image.svg'] = `<svg>🧸</svg>`
return data
}This is different.
3// ----------------------------------------------------------------------------
// 5. make menu code require 2 button module instances, one for small button, one for normal button
// 4. make menu (=`FB_IM`) override button label + reset icon back to original from what button changed
// menu.js
/***********
NOW:
***********/
function FB_MM () {
return { 0: { subs: ['btn'] } }
}
function FB_IM () {
return {
0: { subs: ['1', '2'] },
'1': { type: 'btn:small', override: [override_btn] },
'2': { type: 'btn:normal', override: [override_btn] }
}
}
function override_btn (data) {
data.label = 'beep boop'
Object.entries(data).forEach(([id, value]) => {
if (value.type.includes('icon')) data[id].override = null
})
}
/***********
vs. NEW:
***********/
// FB_MM
function FB_IM () {
return { _: { btn: { 0: override }, 'btn:1#small': { 0: override } } } // btn === 'btn:0'
}
function override (data) {
data['data.json'].label = 'beep boop'
data._['icon:0/0'] = ([icon]) => icon()
return data
}
4// ----------------------------------------------------------------------------
// app.js
// foo.js
// head.js
// ----------------------------------------------------------------------------
// 6. make nav (=`FB_IN`) undo the menu overide for button module instances
// nav.js
/***********
NOW:
***********/
function FB_IN () {
return {
0: { subs: ['1'] },
'1': { type: 'menu', override: [override_menu] }
}
}
function override_menu (data) {
Object.entries(data).forEach(([id, value]) => {
if (value.type.includes('btn')) data[id].override = null
})
return data
}
/***********
vs. NEW:
***********/
function FB_IN () {
return { _: { menu: { 0: override } } } // menu === 'menu:0'
}
function override (data) {
data._['btn:0/0'] = ([btn]) => btn()
data._['btn:1#small/0'] = ([btn]) => btn()
return data
}
5// ----------------------------------------------------------------------------
// 7. make demo (=`FB_MD`) redo the menu override
// demo.js
/***********
NOW:
***********/
function FB_MD () {
return {
0: { subs: ['app/foo/head/nav/0'] },
// PROBLEM_1: this does **not** work: '0' key will overwrite 0 key
'0': { type: 'menu', override: [override_menu] }
}
}
function override_menu (data) {
// PROBLEM_2: how does this "redo" the original "menu override" from menu default data?
data.menu.items.push('demo')
return data
}
/***********
vs. NEW:
***********/
function FB_MD () {
return { _: { app: { 0: override } } } // app === 'app:0'
}
function override (data) {
data._['foo/head/nav/menu/0'] = ([menu]) => menu()
return data
}There seem to be some issue with your version:
|
Tasks -
|
Tasks -
|
|
feedback
|
|
feedback Looks good. I have no opinion yet on whether I didnt understand what or why we need something extra for export/import, ...like a I am not yet super happy with the issue:
|
Tasks -
|
|
feedback regarding slotsyou answered, but i'm unclear why we need slots at all in the STATE module. I have a feeling we dont. regarding
|
Tasks -
|
|
feedback slotsOkay, lets ignore slots for now. I think we need to revist them when we finally get to "dataset group mapping and switching" :-) find/searchI didnt entirely understand how this works. In my mind, this can become a simple lookup, where type or path is basically a "unique instance id" and can serve as a key in a key value store to lookup associated data state to be loaded when a module initializes with a non-empty database data/pathyou said it is merged. How does it work and how does it play with other icon overrides defined e.g. in Basically:
Of course, that So we first have to "run" all modules and fallbacks in our head and use the comments to build that hand crafted hard coded expectation in the test script.
|
Tasks -
|
Tasks -
|
|
feedback feedback for worklog 248Sounds good so far. I need to check the example code how the module is used to really understand some of what you explain, such as: I would have been a bit better i believe, if you had started with the example demo app source code, that runs and initialized one statedb after the next and requires dependencies and so on, all the way down and at each step, you could explain what is already known to the STATE module and what it stores, calculates or internally uses to provide the requested state to the diffrent modules and instances. I feel that way it would be easier for me to follow in which order things execute and when we preprocess and why. Other than that - i would request a bit of refactoring: function statedb (defaults) {
const { api, drive, on, _ } = get_module_data(defaults)
const data = drive
local_state.api = api // local_status.fallback_instance
// ...
}
// button.js
function defaults () {
const drive = {} // inputs, files, css, data stuff
const api = function fallback_instance () {} // module.exports
Object.assign(api, { small: function fallback_instance_small () {} }) // module.exports.small, ...
const on = function (subpath, overrides) { return overrides[0]() }
const _ = {
'foo:0': { $: function module_override () {}, 0: { $: function instance_0_override () {} } }
}
return { drive, api, on, _ }
}Basically to change
for example: The above example refactored would look like: function fallback_module () {
return {
// drive: {},
api: fallback_instance,
// on (subpath, overrides) {},
_: {
"app": {},
}
}
function fallback_intsance () {
return {
drive: {
inputs: {
"page.css": { data: `body { font-family: 'system-ui'; }`
}
},
_: {
"app": {
0: override_app
}
}
}
}
}following the pattern or schema: function fallback () { return { drive, api, on, _ } }comparisonCould you do another kind of refactor by literally making the file the same line by line where it is supposed to be the same?
In these, both version, example and example2 are technically absolutely exatly the same, yet it is written differently, which means when i read through the file its additional confusion. Ideally i can only focus on the lines that are DIFFERENT to see where and why things are different with the different approaches. Could you fix that throughout the file? :-) your explanationthank you for all the explanation, but still, whether it is It is otherwise difficult to follow if you arent yet deeply familiar with the code you wrote - which at this point only you are :-) Also, the "example" and "example2" page.js is ideally the same code, where you would first write the "deep overwrite" version and then copy the code and just comment out the "deep overwrites", so it is easy to spot where the differences are when going through the code myself, which i plan to do after the next worklog with the above changes :-) You do explain the page.js code and the overrides and show the logs in the console, but what is unclear is, in which phase and order STATE module functions get triggered by those overrides to build up the internal cache or state step by step, based on what it already knows and so on .... That would be most important to describe and compare between example and example2 :-) |
|
feedback for worklog 248.21.
In essence - we want to keep it modular and minimal and advanced databases should be built on top of the more primitive core instead. 2.
update (243.3): I do think what would help is a comment or an explanation of the "database schema" (or how it is used, e.g. For example - in the code i learn, 3.I couldn't completely understand things, because the Maybe the next videos will answer some of these questions already. Update (248.3): Okay, so Generally, it would be good to avoid side effects as much as possible and keep those limited to a few functions, such as sending over the network or saving to the database. The preprocess and find_super functions would ideally do everything they need to do but without creating side effects, such as updating the database for example. The call So if we refactor more, let's take those things into account :-) for worklog 248.3And if we are already at coding style :-) 1.The preferred pattern of defining and calling function is giving them only a single parameter, maybe sometimes 2 or 3, but never more. An example for 2 or 3 parameters would be to pass a callback to a function or maybe even a callback and an "errback" (but 3 is really rare, because a callback by convention anyway should have All other data, such as the function preprocess (fallback, xtype, pre_data, fun_status = local_status, orphan) { ... }
// to
function preprocess ({ fallback, xtype, pre_data, fun_status = local_status, orphan }) { ... }That is not a big change at all, but it is significant when calling the function, such as: preprocess(fallback, 'module', {id:0})
// or
preprocess(fallback, 'module', data)Because having many parameters makes it difficult to always remember in which order to provide them. If some params are optional but we want to provide "orphan", we have to pass a bunch of preprocess({ fallback, xtype: 'module', pre_data: {id:0} })
//or
preprocess({ fallback, xtype: 'module', pre_data: data })This will help the reader by providing some context of what the preprocess function expects and it also avoid counting the position of a provided argument, like: Same here: clean_node({local_id: '', entry: host_data, path: modulepath})is more meaningful and also immediately gives us the question, should One more naming thing:
By providing arguments, its easier to see on which data a function can act and by returning data, its more clear what the result is ...the result can then be send over the network or stored in a database ...basically side effects should be as direct as possible, so storing in the database is a direct side effect, but storing in a database inside of a function, such as Hope we can change or improve this as well to some degree.
IDEALLY: we would validate that data provided in fallbacks actually has the correct size and shape, so defining generic These validate function are essentially some sort of schema for a specific entry and reading that function and also writing that function with good names and clean code style, will maybe be even better than the comment showing an example of a data entry. Although, that kind of comment could be added inside that 2.
...oh ...i guess you now explain it, by sharing, that I do think "merge trees" is an implementation detail of how the function might achieve this, but Basically, that is the difference between "override" and "fallback". The I guess, doing another refactoring of renaming things or changing parameter lists to single parameter objects and the likes would be useful to steadily improve readability. People don't say for nothing that "naming" is one of the hardest problems in computer science :P In the past, Another refactor we should do to improve the overall situation :-) You also say: ...again, maybe i misunderstand something here. let me know. 3.
Especially, because above we had for worklog 248.4So i'm confused, because // head
foo(sid)// foo
module.exports = sid => nav(sid)// nav
module.exports = function nav (sid) { ... }and we have a sid now :-) Otherwise, it would really be weird and i cant really imagine how nav would be useful or how it would even work. regarding
|
Tasks -
|
|
feedback Some comments based on what you shared.
const errors = []
// ...
validate_shape(data, expected_structure)
if (errors.length > 0) // ...better would be: const errors = validate_shape(data, expected_structure)
if (errors.length > 0) // ...Because that makes it a lot more clear where those errors come from in general. If there would be MORE than one function call between errors and the if check, then it would be unclear which function populated it apart from reading the source. Same feedback basically as shared previously about:
What is still outstanding is the discussion about:
Lets discuss on discord maybe :-)
But you show in the console when changing fallback data, that it seems to work, so i will dig a bit into the source code to understand how. Thanks. |
|
feedback The longer worklog video (26 minutes) is processed in great detail on discord, but is too much information for a worklog comment here, so rather the processed results of that will be added after the next worklog to save some space here :P But it was a good video, quite informative and definitely lots of progress. Thanks :-) |
@todo#19
STATEDB@output❓STATE_v0.0.?The text was updated successfully, but these errors were encountered: