search

node-projects / dock-spawn-ts

A TypeScript HTML Docking Framework (fork of dock-spawn)
MIT License
128 stars 29 forks source link

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

Open evonox opened 5 months ago

evonox commented 5 months ago

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 commented 5 months ago

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 ?? image

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 commented 5 months ago

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 commented 5 months ago

1.) With brotly it will get much smaller

evonox commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

I've a few more questions:

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 commented 5 months ago

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 commented 5 months ago

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

evonox commented 5 months ago
  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