Payload formatters

[johanstokking]

Summary:
The console needs a way to manage payload formatters on both device and application level.

Why do we need this?
A simplified implementation is part of the Console MVP, fully working version for production.

What is already there? What do you see now?

• Implementation in v2
• Code editor component

What is missing? What do you want to see?

• Wireframes (?)
• Implementation
  • Select input
  • The page itself

1. Supported formatters : none, javascript, grpc service, cayennelpp.
   1.1 For the javascript formatter we need a code editor, https://github.com/securingsincity/react-ace should do the job (it is used in v2)
   1.2 For the grpc service formatter we need only a single input for the service address
   1.3 The rest dont need any additional inputs
2. The javascript formatter has only two functions - encoder and decoder

How do you propose to implement this?
Similar to the v2 payload formatter, but without the tester (for MVP)

---

Original issue: https://github.com/TheThingsIndustries/lorawan-stack/issues/1379 by @kschiffer

[bafonins]

Will be a part of the Application Link page, see #214

[kschiffer]

Forwarding for completeness (original from @bafonins ):
After a quick discussion with @johanstokking, we agreed that the resulting page in the v3 console will be similar to the one in the v2 console. However, there are a couple of changes for the Console MVP:

1. No payload tester
2. Supported formatters : none, javascript, grpc service, cayennelpp.
   2.1 For the javascript formatter we need a code editor, https://github.com/securingsincity/react-ace should do the job (it is used in v2)
   2.2 For the grpc service formatter we need only a single input for the service address
   2.3 The rest dont need any additional inputs
3. The javascript formatter has only two functions - encoder and decoder

[bafonins]

Will be a part of the Application Link page, see #214

Reopening since the Application Link covers only the bare minimum of linking.

[bafonins]

I can imagine the top-level tabs can cause problems on the Device Overview page:

Having 3 levels of tabs i definitely not a good solution.

cc @kschiffer(suggestions?) @htdvisser

[kschiffer]

We shouldn't use tabs to select the payload format type (JS, GRPC Service, CayenneLPP) anyway because a tab is not a proper input element. Yet the user needs to select an option here explicitly, which is why I used radio-buttons instead.

For switching to encoder or decoder, we can use tabs, because it is just changing what the user wants to see/edit from the formatter and the integration into the form makes it scoped enough to not interfere with the other tabs.

[kschiffer]

For application level:

When application is not linked:

Feedback welcome.

[htdvisser]

1. We should use the correct terminology. These are message payload formatters
2. You can configure two formatters: one for uplink and one for downlink. It is possible to use different formatters for uplink and downlink.
3. Each configuration of a formatter consists of
   A. The "Formatter" that can be one of NONE, GRPC_SERVICE, JAVASCRIPT, CAYENNELPP. I don't know why REPOSITORY was omitted in Payload formatters #71 (comment) (@johanstokking?)
   B. The parameter (editor for JAVASCRIPT, a regular input for GRPC_SERVICE, nothing for the others)

As a result of (2) I'm first of all not sure that the v2 terms "Encoder"/"Decoder" should be used. Secondly, we should split uplink and donwlink parts and put them both on the page. It's perfectly resonable to think that someone would use CayenneLPP for uplink, and JavaScript for downlink.

We can get rid of the "Remove Formatter", because removing it would be achieved by setting it to "none".

[kschiffer]

Thanks for the input! In that case, listing the uplink and downlink formatter options below each other is indeed better. I was experimenting briefly with using tabs to split uplink and downlink messages but that will result in unnecessary workload and also possibly confusing UX in the device context because there would be two tabs right below each other, as @bafonins pointed out. Also, the form is at this point lean enough to show both.
We can adapt the design progressively once we add functionality then.

[johanstokking]

Indeed REPOSITORY is a valid option.