Structure of adapters using REACT
Closed this issue · 7 comments
At examaples repo adapters using REACT as admin ui have the following structure
admin/src/ ...
Whenever @bluefox adapts or creates an adapter using react admin ui the following structure is used:
src-admin/src/...
Please coordinate whats the goal for future adapters and discuss with bluefox / at meeting and adapter creator afterwards. Its confusing if ther is no clear structure what's up to date good practice
I really don't know if we need to force everybody to use the same directory structure. The adapter creator and the templates are an easy way for developers to create adapters, but if adapters are created manually, IMHO the developer should have the freedom to do whatever they like (that's the beauty of ioBroker adapters). At the end, the adapter must work and there might be reasons for different directory structures and configurations for advanced developers. We don't need to have a tab vs spaces discussion ;-)
AFAIK (unless this has changed) bluefox adapters tend to have multiple npm projects in one while create-adapter generates one project where everything is installed at once with npm install.
This is definitely opinionated but IMO less complicated. I don't think there's a good reason to change it.
In meantime I got more information.
The situation has nothing to do with multiple NPMs.
BUT thre are multiple react subsystems within the adapter. See i.e. backitup. simatec/ioBroker.backitup#1148
Well - I agree that possible no change is required. But the react usage make thinks more and more confusing ans less maintanable :-(. Now we have 3 i18n Trees with differnet names and two distinct react blocks in one project ...
Dont think that anyone besides bluefoix will be able to maintain this stuff :-(
I really don't know if we need to force everybody to use the same directory structure. The adapter creator and the templates are an easy way for developers to create adapters, but if adapters are created manually, IMHO the developer should have the freedom to do whatever they like (that's the beauty of ioBroker adapters). At the end, the adapter must work and there might be reasons for different directory structures and configurations for advanced developers. We don't need to have a tab vs spaces discussion ;-)
I think we should try to keep one or a small number of structures. Maintainance is much more complicated if basic structure is different. This becomes a problem if the original maintainer does no longer support the adapter. Technical reasons are a good reason for differences and I have no problem with them but I do not have time and energy to search new adapters where they could have hidden text when linking them to weblate as an example. Such adapters might be left out from tools - and eventually I will not accept them at repository due to failing tests and missing tim eto do manual checks.
I don't see a problem with the directory structure for the translations.
This should continue to represent the flexibility of ioBroker.
In the example of Backitup, we now have almost all the variants. There is a tab menu in react where translations are needed.
Then we have the standardized jsonConfig, which also corresponds to the standards in the translations.
But we also have react components in the config that Backitup needs in the config and the translations are also needed there.
Furthermore, jsonConfig also offers the option of creating the translations directly in json5.
@mcm1957 You can standardize a lot of things, but ioBroker is basically very flexible and I think we shouldn't ruin that with all the standards.
I got the information that there are technical reasons to have more than one place for i18n files in combination with react. But nevertheless I think that random filestructure is no good idea. I do not see ANY benefit if some adapters use i18n/<lang>/translation.json and others i18n/<lang>.json. And at least if someone thinks he / shw must change to the other structure this only creates effort at weblate.
OK, we can discuss to drop weblate too. But IF we want to use such a tool, please do not make the work harder than required.
I will accept a limited number of typical structures like backitup is using currently. But if variants continue to grow I will drop weblate support.
Besides "translations directly in json5"should be avoided in my oppinion as this blocks weblate usage, Again - we might discusse the usage of weblate but we should not promote inconsistencies between adapters.
AFAIK i18n/<lang>.json instead of translations.json was introduced by adapter-react if I'm mistaken and create-adapter merely adopted it.