Dynamic TAK content from a Rune tool generated JSON file

[thejhh]

Implements a dynamic tak documentation from a JSON file generated by the Rune YAML preprocessor tool.

This is not currently complete refactoring, but can be changed to use the old components which are still present.

Starting points where the implementation is in use:

• See SoldierView.tsx: <ServiceView name={'ServiceTak'} />, original was <ServiceTak />
• See AdminHomeView.tsx: <ServiceView name={'ServiceTak'} />, original was <ServiceTak />
• See i18n.ts: use of CONTENT_SERVICE there to load translations
• See ContentService.ts: This file reads the data from ./data/tak.json
• See ProductContentRenderer.tsx: Every implementation is in the render() method

When/if you edit YAML files inside the data folder, you need to run the make build at ./data folder. This can be automated for development by:

while true; do sleep 1; make; done

[benjamsf]

Running with backend (1.9.0+integration api),
pvarki/docker-rasenmaeher-integration#148
few issues:

1. need caching / optimization

• long loading time the 'rune.json' from integrationapis
• presently it does not cache it so we get waiting each time we go homepage

2. backend version 1.9.0 probably borks something

Or the backend/takintegrationapi won't deliver:

3. complex?

Product/ProductContentRenderer is 650 lines long.

Ofc it offers supports for every our reactcomponent but it still seems heavy. Options I could think of:

• Break the component support down for product/renderer/{component} for each our component (also make the idea of Rune library bit more portable, so that we can write component support for Rune for each new component we happen to want to make
• Larger question, is this the approach best we could take? It kind of feels of an ui inside our ui.
• • I mean if we'd lighten up rune-dynamic-content to just couple of modals, dropdowns and buttons you ought to deliver in RMUI. Then deliver the actual userguides utilizing https://github.com/pvarki/Docusaurus-docs
• • Though we would have to solve this dynamism once again, but there probably docusaurus-md & supported reveal-js would do the CSS magic to render them instead of having work it all custom.
• • If so, work wasn't futile though because Order App (refactored) might benefit from the approach, As it - at least -should offer comparatively large amounts of information about {products} available Today, anyway.

4. Need docs

Going to need a sequencediagram of what happens, though looking it for a while makes the basic idea understandable

[benjamsf]

Okay, so some talks & progress with @karppo & backend:

1. We could offload some images to integrationapi src/www_data so that we don't need to include them to the rune Product.JSON, so making those json:s smaller
2. Karppo working on in it, backend-side
3. Complexity matter:

• a. We could use Rune Product.JSON ui dynamic content only for functional things users need to access that product (minimal what's this information, downloadzip/config-modal, link button to possible browser app, link button to DocsV2) instead of writing guides to Product.JSONs
• b. Then instead write the guides to DocsV2 that is, docusaurus with our minimal additions (such as reveal.js) and we need not to write/upkeep that heavy ProductContentRenderer. Ass docusaurus & revealjs will take care of CSS matters, product integrator just writes some markdown and supply images.
• c. this approach means that we should cut Product.JSONs to be small (to be efficient & fast) and then have the bulk of guides in docsv2 => We need to merge IntegrationApiV2 and Docsv2 to a same version tag
• d. we need to solve the dynamism issue in DocsV2 then but per initial talks, that should be doable