Client Apps

[Paul Bouzakis]

Has anyone attempted the clean architecture with a client app (fat client - for example a JS SPA)? The main difference here is that the view needs to be reactive, compared to server side where you just render and return a string.

Are my view models observable? The presenter gets a response model but it's just a dto, so how is the view informed of updates? Or is the response model observable so we can bubble this up to the vm via the presenter?

Let's say I have a View Contact Details use case. Eventually the UI renders the details but we have to keep this view in sync with an entity (for example the contact name changes). The changes can be fine grained, so any part of the view might be updated.

The interactors are stateless so I don't think it's good to keep them long lived to simply listen to entity changes. It would also then be told by the presenter to stop listening as we'd want to prevent memory leaks when the view is disposed.

Uncle Bob any thoughts for us client devs?

[Paul Bouzakis]

Well this is sad

[Norbert Nemes]

Simple! One solution is that the presenter calls the view (delegate patrern). And yo do not need to keep the interactor around if you do not want to. You can create a use case factory that the presenter calls to get well... use cases. But this has been discussed on several other threads as well.
Hope it helps.

[Andrzej Krzywda]

For me, the trick was when Web Sockets (we use Pusher as the proxy) became available. 

The server can now push information to the client. 

In some situations it may be safe to assume that the server worked fine and not wait for its response (but react if it's a failure). Doesn't fit well for buying actions, but may fit well for just "saving" some data.

Here's a talk where I presented a Use Case approach (heavily UncleBob-influenced, but with some extensions - AOP, DCI) in a typical Single Page Application 

https://www.youtube.com/watch?v=ENVPZ-UoQsg

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.