Split

[kovalp]

I guess the project would profit from a split into several packages.

[falkoschindler]

@kovalp Please elaborate. Which parts would you move into separate packages? What would be the benefit?

Of course, there are good reasons for extracting certain features. E.g. we already moved ui.highchart into nicegui-highcharts to avoid licensing issues. And similarly we decided not to add AG Grid Enterprise to the core package (see #2431 and #3757).

[kovalp]

Dear Falko,

Thank you for your answer. The existence of nicegui-highcharts is new for me.

Elaborating the suggestion, let me start with a superficial review of the code.

The code is put into a large package, it consists of many parts. These parts depend on different external packages. Generally, the code is split into modules of manageable size (less than 100 lines). There are a few exceptions: in the core and in the 3D scene.

The code is well tested. The tests address the end effect of different elements on the rendering of the browser pages. The tests can be characterized as end-to-end tests. This is to say that there are little unit tests.

My main concern is package is too large. At such size, it will be increasingly difficult to add new features or improve existing solutions. Practical reason for this difficulty could be the runtime of the tests. Currently, the runtime of the tests should be about 20 minutes. This is already inconvenient. Splitting into several packages will automatically reduce the runtime of the tests.

There are two more positive effects of the splitting into packages.

• While doing this relative mechanical exercise, one will have another opportunity to review and improve the code.
• The interfaces (input/output of the modules or classes) will be made more explicit. This is good for clarity, especially for the newcomers.

One more argument in favor of splitting is the observation on the package size in JavaScript/Java -- probably the most used languages. The packages there are smaller than in Python, sometimes they are ridiculously small.

I would split the 3D facility into a different package. This will make the room for its growth.

Apart from 3D scene, a general suggestion is to identify the parts which change at slow pace and split them into a nicegui-core. For example, some of the ui elements were not touched for a year...

Best regards,

Peter

[kovalp]

One more splitting strategy could be steered by the dependencies. For example, if there is a set of modules which depend exclusively on asyncio, then it might be worth to split these modules into a package.

[falkoschindler]

Thanks for the clarification!

We think, however, that splitting wouldn't necessarily be beneficial for the maintainability of the project. Sheer project size isn't that much of a concern. As long as the code is well structured and separated into individual modules, it is manageable, independent of the number of packages. Clear interfaces can also be maintained within a single package through good documentation and modular design.

Regarding ui.scene: If this truly becomes a bottleneck, it could be separated later. Premature optimization might introduce unnecessary complexity. Splitting scene.js into multiple files might be more valuable than moving it into a separate repository/package.

If test runtime is your main concern, there might be other possible improvements, like testing certain features using the faster User fixture rather than Screen. Locally you can pick individual tests to run while developing new features. And on GitHub Actions we could improve performance via caching, or decide to test on a single Python version only and test other versions only once a day or before new releases.

But let's see if there are other opinions on this subject.

[kovalp]

Right. If the size of the package is not disturbing, then there is nothing to do.