Compartmentalizing logic

[nordfjord]

Nice Harry Potter reference

[pshomov]

@nordfjord I am not much of a references guy (nor am I a Harry Potter fan) but this was one was no brainer - nice name and a geeky reference ;)

[bigloudjeff]

Hi Petar,

First off, thank you for work you have done on Reducto and for the great blog posts around it. A colleague and I have been have a discussion about where the best place to persist data in this type of pattern would be?

You mention middleware several times but I don't see any actual implementation or samples for it. Would middleware be the place where one would implement their data persistence?

The scenario we have been discussion is in an invoice system you have an action to add a line item to the invoice. Where in this model would you enforce some business logic (i.e. a max of 10 line items is allowed per invoice) and then where would you persist the new item to your data store?

Just curious about your thoughts in this area. I can post this as a comment on one of your blog posts if you want to respond in a forum where others can participate.

Thanks!

Jeff

[pshomov]

Hi Jeff,

I am glad this is helping someone. I have not been doing anything around UI development since I developed Reducto so I have not used or thought about it much at all (unfortunately). Glad someone is looking at it ;) Would be glad to consider any contributions should you have some and feel generous.

About the persistence - you should use async action for that. It is possible that middleware might do to, but async actions were created exactly for this kind of thing. I did not get around to demoing middleware I think but you might look at some of the tests to get an idea - https://github.com/pshomov/reducto/blob/master/src/Reducto.Tests/MiddlewareTests.cs

About the async action thing - look at the last paragraph of https://github.com/pshomov/reducto also http://pshomov.github.io/better-mvvm-with-xamarin-forms/#async-actions. Instead of calling a webservice to authenticate the user, you might add a an invoice line.

I would wrap the calls to the invoice API in a separate object and do any rules (such as the max 10 per invoice) there. Easier to test and also those rules are not relevant to the UI (I am assuming you are thinking about Reducto as a support of your state for your UI).

Remember that you can google also these kinds of questions about Redux and the answer should still be helpful, after all Reducto is just a port to .NET.

Best regards,

Petar

[gaui]

We need to port this to .NET Core 😉