ged-odoo / blockdom Goto Github PK

It probably does not help that the moveBefore method is not implemented for list

Please share the latest and updated source of the Tomato framework inside examples too.

Hi,

Thanks for your great library, truly awesome.

May I ask you to enable the Discussion feature of the repository to ask our questions and talk about details?!

Creating issues every time for some questions does not look good.

Thanks.

in the tutorial, we have a limitation for the tomato framework: we need to manually use the multi block if we want to do a fragment, but it would be more natural to simply write the fragment in the template. It would be nice if we could do that, and return underneath a multi block. main issue is that we need to redistribute data into sub blocks

Hi,

I suggest you add TypeDoc documentation results for easier learning.

I did these inside my system but I don't know how it is possible via Github or any other online facility.

This API doc completely covers your tutorial. (more JSDoc = more API description)

Easy to use

1. npm i typescript -g
2. npm i typedoc -g
3. npm install
4. typedoc .\index.ts

Currently, blocks are created with 2 sub lists: data and children. But in practice, it may be easier to use a simple list, mixing everything. Let's try that, and benchmark it before merging it :)

It currently uses a boolean to check if a subtree is dynamic or not. But if instead of a boolean, we uses a number that represents the actual count of references (and it is easy to construct, since we can simply increment a counter on a tree and its parents whenever we find a dynamic element), then the problem of allocating indices is much easier. There may be a way to reuse an already used indices when going down in the right subtree

It is undefined. So, need to fix that, and make sure a test should catch it

need to check if we can do it without the parentnode. this would reduce memory footprint

Now, blockdom keep an array of refs with all the nodes necessary to reach the target refs. But it can be reduced to a smaller number of refs.

1. The "easy but not optimal" way is to compact chains of single nodes in one. So, if I have <p><p><p><block-text-0/></p></p></p>, we can reuse the previous index to store the next reference when computing them, and end up with an array of either 1 or 2 (depending if we keep el in it) references.
2. The "optimal" way is to compact all chains of consecutive nodes that are only used by one path into one. This is the same as above, except that it works in a more generic way.

otherwise, it may not work with some kind of elements such as <td> or <tr>. See https://twitter.com/WebReflection/status/1435840285632835586

need to use a template tag

Instead of having internally a

• data updater/setters list
• children updater/setter code,

we could have two lists of functions, setters and updaters. They would not necessarily have the same length (for example, see the refs code: no need for updater). And this means that the mount/patch methods would only have to iterate through that list and call the function with the refs/datas as arguments. These setters and updaters would have the refIdx and dataIdx captured in a closure.

Is that more performant? not sure. possibly, but the risk is that it is actually an extra function call that may not be inlined?

one for the compiler (the main one), and one for the runtime