Public Request for beta-testing of the new docking library.

[evonox]

I am just before finishing the pre-alpha version of the new DockerTS library. Could I ask for the public testing? Pre-alpha demo version of the library you can find at: https://docker.robotkarel.cz/ . If you find any repeatable error scenario, please submit me issue at: https://github.com/evonox/docker . Thank you very much for any support, suggestions or opinions of how to make the new library better. It will be released using MIT license for the benefit of the whole community.

[jogibear9988]

1.) I'd love if you could remove the additional dependencies. We don't use lodash, and it only used for depbounce, throttle and deep, I'd love if it could be removed.
For velocity-animate, I don't know, if it is really needed, but seems not to be a good idea to use a lib wich has no updates since 4 years.
2.) red flicker when I undock: https://app.screencastify.com/v3/watch/w3PNa58cM0HlIxo6oVH0
3.) One major issue: What really will not work for our system, is that you remove elements from dom and add them to other nodes. I changed dock-spawn-ts completely so that the container wich has the user content is never removed or moved to another dom node. Cause if you have really huge pages, this is verry slow. I alwas position them absolutely and only move the dock nodes around
4.) The library should be published as an ESM module. Also the type in the package.json should be set to "module". We have a no build setup, so we include very lib directly as ESM via an importmap, and every javascript library today should be usable in this way
5.) why jquery in docker-ts.js ??

For me it really looks nice, and I'd love to use it, but I can only when the dome nodes will stay in DOM

[evonox]

Dear @jogibear9988 ,
thanks for your comments and suggestions.
I will address your requirements as follows:

1. I understand the need for zero-dependencies. However we need the lodash functions for performance reasons as well as velocity-animate for fast JS animations. However I can address this issues as I will extract those few Lodash functions to my own helper class and remove the dependency. As for the velocity-animate, it is sad this good library is not maintained, I will replace it with my own JS animation framework. I do not write simple JS animation library for the first time. The other benefit for removing the dependencies is that we will decrease the JS bundle size. It is I think around 200kb without CSS which is quite a lot. My dream is to get with JS and CSS to around 50kb gzipped size.
2. I have a question. As you have noticed, I do not download WheelItem images, but inline them inside CSS. Is that ok for you? It has two reason. We reduce the number of HTTP requests the server needs to do and the second, we will have only two files for deployment.....CSS and JS file.
3. I apologize for the red flickering. It is not bug. I just noticed I have deployed the debug version of the library. I use red backgrounds exactly to find out, where the docking library is slow and needs optimizations.
4. I understand the DOM issues. It is one of major tasks that is still awaiting addressing. I will review this issue completely, not only adding DOM nodes but also implementing some diffing algorithms as you have in your DockSpawnTS in SplitterPanels and TabHost.
5. ESM will be created. This demo is just for presentation purposes. The library is not meant as production-ready now. It will take some time.
6. jQuery issue is quite funny. The reason it is there is the originally velocity-animate library was developed to replace slow animations inside jQuery. So this library is detecting if jQuery is downloaded to substitute its original implementation for animations. The sad thing is this library is no longer maintained so we have to remove it. The other argument for removing it is also the bundle size as I have written. I will implement its simplified version and substitute it. We will save a few KBs hopefully.

[jogibear9988]

1.) With brotly it will get much smaller

[evonox]

I think, the next week I could have prepared the beta version that might be a candidate for production-ready version of the library. There is however plenty of things to fix.

[jogibear9988]

Will you also support undock to new window? It would be nice if this could work, also with support of docking back...

Maybe you've seen the support in visual studio code?

[evonox]

@jogibear9988
Do you mean undock to a new browser window? I have it as one of the future features to implement. I want to support also collapsers like wcCabinDocker has and the support for perspectives like in Eclipse IDE. But first I want to publish the docking library quickly to NPM registry to start the public testing completely. By publishing the first version my work on this library is starting, not ending.
By the way, we need to create the new library name. I asked in one FB Czech frontend group for opinions and there was critisism as DockerTS is not a good library name because it is similar to Docker technology which might be a trademark. Do you have any idea how to call it? Maybe I do not mind even if it might have the same name DockSpawnTS.

[jogibear9988]

There are different ways to do it. If you look how I've done it in dock-spawn-ts or how vscode does it. I move the component to the new window. This is very fast. If you look how it works in golden-layout, very slow.
For me it is essential that also web-components with attached stylesheets work, for this I build a hack (if you look at my code (https://github.com/node-projects/dock-spawn-ts/blob/master/src/BrowserDialogHelper.ts). And I've not yet implemented docking back to the origin window.

e could release it as a new version of dock-spawn-ts, I like it, it feels already much more professional. I only did small changes to dockspawn, never did a big rewrite (only the change to keep the nodes in dom).

[jogibear9988]

I've a few more questions:

• Is there a option for every button in the Panels/Dialog? Like IsCloseable, IsMinimizable, .... I think if I use it I will need this to be configurable
• What will the close button do? Remove the content also from DOM or only hide it? Should this be configurable? For example I've tool windows, wich I only create once. You could close the in docksspawn via "x" but I also could show them again.

And you asked about the icons, they are not mine, I used the from the initial dock-spawn project.
But there are also some in https://fonts.google.com/icons?icon.query=dock

[jogibear9988]

I also had a webcomponent wraper for dockspawn, may something like this should also be added, maybe as an extra npm, but in dockspawn it added not much of size, see:
https://github.com/node-projects/dock-spawn-ts/blob/master/src/webcomponent/DockSpawnTsWebcomponent.ts

and most of the code are only api duplications, wich for sure could be done nicer

the main idea was, you could define your docking ui, without any javascript.

[jogibear9988]

I used it the webcomponent for example here: https://node-projects.github.io/web-component-designer-demo/index.html

[evonox]

1. As for the undock / dock feature to new window I will make it one of the priority issues for extension. I want to support anything that is requested and make the library better.
2. Of course, it will be possible to specify if window can be minimized or closed, etc. It will be possible for each panel separately. I am in the process of writing the documentation. I propose we can then discuss the APIs if they are OK for you. By the way, you will have APIs giving you the full controls over the header buttons. You could even add your own custom header buttons. The same is true for the context menus where you will be able to define your own menu items.
3. As for the close button, it will by default remove the panel from the DOM. There will be however an option for Ghost Panels, that will exactly do what you request. They will be hidden by display: none and when you invoke to create such panel, it will just show again. So you could use default behavior or ghost panels upon the scenario you need.
4. The icons you have are fully OK for me. The next week I will have a videocall with my friend who is a graphics designer to discuss default coloring theme, animations, and possibly the icons. I will ask him for his opinion and we will see. The thing I need to mention is that theme of the new library will be fully configured by CSS custom properties, so possible to change in runtime.
5. For the web components, or what I understand as the need for declarative definition of layouts I would propose to take a different approach. I will explain possibly in a PDF document I will include in this discussion thread. Briefly said, the docking library is designed to support micro-frontend applications where one panel could be in React, the second using WebComponents, third VanillaJS or using Vue technology. This does not mean, it is not possible to create declarative definition of layouts. We can use element to specify it. I a bit count on that users of this library will need to use it for large applications composed of multiple micro-frontend frameworks which can be built separately by different teams and deployed separately.

[jogibear9988]

I mean, I'd like a webcomponent version, so the user of the Component does not need to write any line of javascript to use the component. At last it is only a small wrapper for the normal API, but declartively usable. It has nothing to do with the other frameworks, like vue, react,... webcomponents are browser standard, so they work always, if you use a framework or not.
But it can be included later. But don't compare it to angualr, react and vue, cause these are librarys and webcomponent are browser standard

[evonox]

@jogibear9988
Could you please give a proposal of the definition your web components you would like to have? I mean the properties, events, etc. Do you use Lit Framework?

[jogibear9988]

No, i used no framework.
Will do the proposal

[evonox]

Dear @jogibear9988
The second project I have hidden in GitHub private repo is my first attempt to create a pure WebComponent UI library. I use the Lit Framework which is provided by Google. https://lit.dev/docs/getting-started/
As for the WebComponent it saves quite a lot of work. I just send you a link if you want to give it a try.
I have noticed somewhere you create a visual editor and you write you have a base widgets library in Web Components. This is I think our mutual interest and I would love to discuss with you creating a pure Web Component widgets UI library. What do you think?