2

I have written a new shiny Todo service with my favorite front-end and back-end framework. To minimize coupling I return data in some standard format like JSON or Protobuf and leave it up to the client to interpret and display it in a way it feels suitable.

The user can select multiple items which on selection should show different UI as compared to normal item, it can be done by adding selected field to the objects as soon as I receive them on the client, setting them initially to false. But later I would need to sync the application state with the server and I wouldn't want to send the original data with the selected attribute hence before sending it back to server I must remove the selected attribute from the objects.

Since, javascript in my current choice for dealing with front-end code so, it seems pretty trivial to add or remove fields on the fly. But suppose I need to add 10 more states to my front-end then I need to do Augment my original Model again and again.

I need to know is this the correct approach to deal with such a situation?

  • Why don't you use the DOM to bind the Info and states you need? You can add as many data-attribute=value as needed. If you need to persist such states for further sessions, then use cookies. I don't like to use cookies but they were made for this propuse. To persist data at client side. The less Info su store in cookies the better. – Laiv Apr 16 '16 at 15:15
2

I think the root of your problem is that you are not using compositional patterns correctly. Instead of changing the model of these items, create a NEW model, which contains these items. That way the original identity and composition of these items are preserved.

This article gives a fairly balanced look at the problem (even though it is targeting Java): http://www.javaworld.com/article/2076814/core-java/inheritance-versus-composition--which-one-should-you-choose-.html it isn't exactly appropriate as a reference, as it is talking about class based inheritance, and you will have to do some conceptual juggling to get to prototypical inheritance, but its principals are sound.

  • I am taking about frontend if you read correctly. – CodeYogi Apr 15 '16 at 12:46
  • @CodeYogi: and so ... ? As pointed out by Rob, stop mixing (ie. "Augmenting" in your own terms) your models and you'll be fine. You could extend your data model with the view's needs as Rob suggest. You could also use a pair of models - one with the Todos, and one with persistent view data. – Tibo Apr 15 '16 at 13:56
  • @Tibo so, basically what you are saying is create a VM for every model from back-end and the VM should be responsible for managing the UI states. – CodeYogi Apr 16 '16 at 3:21
  • No, I don't think you have a VM for selected items on the back end (maybe I'm wrong). The point is that there is another model here, the selected items. It's not really a view model, it's a model that sits in your view, but if it helps to think of it as a view model, go ahead. This is not a "do this every time" sort of solution, it just happens that in this case, there are multiple models here, and putting them all into one gives you the kind of issues you have been having. SelectedToDos is a model (or VM if you wish), and ToDos is a model. – Rob Conklin Apr 16 '16 at 12:49
  • You could solve this by having a View Model where the IsSelected flag exists on the element. That would dissolve your issue in a different way. It would be embracing View Models instead of Models. The thing you are sending back and forth right now is not a View Model (because it is not providing the boolean checkbox). These have gone out of style a bit lately as most back-end services have multiple heads, and making ViewModels that are bound to a particular application is not popular. – Rob Conklin Apr 16 '16 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.