Closed johanstokking closed 5 years ago
Will be a part of the Application Link page, see https://github.com/TheThingsNetwork/lorawan-stack/issues/214
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:
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 inputsWill be a part of the Application Link page, see #214
Reopening since the Application Link covers only the bare minimum of linking.
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
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.
For application level:
When application is not linked:
Feedback welcome.
NONE
, GRPC_SERVICE
, JAVASCRIPT
, CAYENNELPP
. I don't know why REPOSITORY
was omitted in https://github.com/TheThingsNetwork/lorawan-stack/issues/71#issuecomment-469720772 (@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".
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.
Indeed REPOSITORY
is a valid option.
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?
What is missing? What do you want to see?
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