UI: Methods in shared/EdgeConfig.ts returning EdgeConfig.Component[] -> sort via component alias
Description
src/app/shared/edge/edgeconfig.ts -> methods returning an EdgeConfig.Component[] sort their content via component.alias.
Methods
- getComponentsByFactory
- getComponentsImplementingNature
Reason
This is mainly a beautification within the Flat/Modal Widgets of Live and History.
We got feedback of users, and they find it more visually appealing, when the widget contents are sorted by their "name" (alias) This simple sorting would solve this request.
This may be in your interest too.
Co-authored-by: Ulrich Laupp [email protected]
i dont think this makes sense, seperating the "common" widgets and controller specific makes sense, alias shouldnt be deciding in my opinion. I think it makes sense for controller widgets.
i wouldnt do the sorting here, you could do this in widget.ts
Hey,
Thank you for your input and sorry for my late reply.
I thought about your comment and I think we should discuss on this topic a little bit more (or shift the discussion to the community forum if this is preferred.)
I'd like to know:
- why a general sort with alias is not a good idea, since (especially the common) widgets display their components with the corresponding alias and value, instead of the componentId (Examples are given when click on the details tag)?
- Does this break something, that I am not aware of?
But let me explain our usecase a bit more in detail.
This change should only change the sort order of components within a widget and shouldn't sort the widgets themself.
Currently the widgets are unsorted / picked up by component Id. Resulting in some randomness (for the user) as you can see within the following details tag, especially if they adapt the component alias, resulting in this:
**Click Me** to show some pictures showing the difference between unsorted/sorted by alias
Unsorted
History Flat Widget
History Chart
Live Flat Widget
Therefore I made the change within the edgeconfig.ts
Resulting in this:
Sorted
History Flat Widget
History Chart
Live Flat Widget
Additionally:
You suggested, that I could make those changes in the widget.ts However: The sorting within the widget contents wouldn't work.
If I'd change the widget.ts and do a sorting by alias in the same way you sort the channelthreshold by the output address like:
explicitely sort ChannelThresholdControllers by their outputChannelAddress
https://github.com/OpenEMS/openems/blob/f6aa692fc5f97961b6c06c16452f51265cc9c8f3/ui/src/app/shared/type/widget.ts#L104-L116
I wouldn't change the sort order of components within widgets, as you can see here for example:
/ui/src/app/edge/live/common/production/flat/flat.ts
https://github.com/OpenEMS/openems/blob/f6aa692fc5f97961b6c06c16452f51265cc9c8f3/ui/src/app/edge/live/common/production/flat/flat.ts#L23-L26
If I shouldn't create a general sort by alias, I'd need to go through every flat/modal/history widget/modal/chart and see if I'd need to sort the components by their alias, since they display different components.
My personal conclusion is, that a general sorting by alias makes sense, since the UI displays components showing their alias (especially the common widgets/charts).
I hope this made things more clear. Thank you for your input in advance.
@DerStoecki Thanks for the detailed explanation. This sounds reasonable to me. I'll leave it to @lukasrgr to decide if the technical solution is the best way to do it.
Hey, i misunderstood it then, pretty good explanation, i think you actually have a good solution here. I just want to remind, that its still not guaranteed that the alias is set, especially for older systems. Use the helper var Name.METER_ALIAS_OR_ID.
ids and alias are used in the same context, but this is - i could think - expected
Hey @lukasrgr ,
Thank you for your input. I adapated the comparison as you suggested. Thank you!
This PR has been automatically marked as stale due to inactivity. It will be closed in 7 days if no further activity occurs.
This PR has been closed due to inactivity
It was automatically closed because there has been no recent activity. If the PR is still relevant, please feel free to reopen and update it and add any new information.