Replies: 3 comments 14 replies
-
It's not easy to load templates from a folder not listed in settings.TEMPLATES[0]["DIRS"]. This could either be done using a custom Loader, by monkeypatching |
Beta Was this translation helpful? Give feedback.
-
Strong supporter of this proposal. Would the server methods go in init.py? I slightly prefer the second layout with the name of the component for each file type. I would propose keeping the existing ability to have the template and script inline with the python as an option, I do think there is a benefit for speed and ease of getting started to have that which can then extend out to separating the components when necessary. Would this eliminate the need to register and setup component libraries manually? Essentially the directory becomes a library? |
Beta Was this translation helpful? Give feedback.
-
Loving the new approach! Works very well - Here is a PR that makes the auto rebuild work for template files found in the component directories - #77 |
Beta Was this translation helpful? Give feedback.
-
Components as code are nice for small components with 3 lines of HTML code. But as they grow more complex, they soon get unmaintainable. HTML + JS + CSS code is not well supported in IDEs when trapped in python strings (even if @samwillis wrote an integration for VsCode). PyCharm won't implement this soon, and there are many other glitches like caching, missing IDE helpers (including AI) etc. - syntax highlighting is not enough.
Directory based layouts have some advantages:
So I propose adding support for component modules as directories with the following structure:
There has to be discussed whether the names of the files should match the component name, like
The first allows faster renaming of components, the latter better finding the components' files using their names.
The
__init__.py
should be the entry point, as it is needed anyway. I tend to implementing the first approach.I think a management command to create components would be good as well, like
component-in-a-class vs component-as-dir
Another important question. Should the current component-in-a-class approach be kept?
It would break the API completely, but as Tetra is a relatively new project, things are prone to change, and I am not a fan of keeping old habits - if there is not a really good cause. A good cause would be: >=v1.0.0, stable API, heavily used in production.
Tetra is growing, and I think the components-as-a-directory approach is the much better one.
So I tend to migrate completely to the directory approach.
@gsxdsm - opinions?
Beta Was this translation helpful? Give feedback.
All reactions