Open to feedback

[csmets]

Welcome to SDUI! 👋

Thank you for taking interest into this project! I have worked on building SDUI applications for a number of years and have resulted to form my own opinions to what I would think is best from the many lessons learned and have contributed it here. Whilst my opinions feel sound to me, they're bias. This is why I need you to share your knowledge to help build a robust guide to help educate others into this paradigm.

If you dislike SDUI, share them into the discussion but give me the reasons why. If you love it, also tell me why. Your feedback is welcomed and appreciated.

[elsonwu]

Thanks for sharing this great example repo, I have some questions when things get more complicated.

In the complex UI, how to keep the resolver simple and easy to maintain?

• The data from different data sources, which might need some filtering, transformation, etc.
• The text with dynamic date + localization, like the simple case, Hello {name}.
• Interaction between elements, like when in the payment form, the user put in the coupon, the final amount would be changed, or turn to red when it's an invalid one, etc.

Thanks in advance: )

[csmets]

Apologies for replying almost a year later.

To try and give an answer for these points:

• The data from different data sources, which might need some filtering, transformation, etc.
• The text with dynamic date + localization, like the simple case, Hello {name}.

Avoid multiple fetching and forming your data within the resolver. The resolver should only be focused on figuring out how you want your result composed supplying it with data, not handling any business logic. Strictly making the resolver only having to do 1 fetch/network request keeps the complexity low.

Text or localized strings should be composed on the server-side. The request should be able to provide some form of context to be able to get server user data via a user token or some kind of authentication. This would be the same for date time as well.

• Interaction between elements, like when in the payment form, the user put in the coupon, the final amount would be changed, or turn to red when it's an invalid one, etc.

For this I would use a combination of actions and signals.

Create an action that would handle the case for a coupon, and use signals to handle changes as if it was an observer