andrei15193 / react-model-view-viewmodel Goto Github PK

The reduce method on observable collection receives improper parameters when executing the callback.

The following code sample exposes the bug:

const observableCollection = new ObservableCollection<string>();
observableCollection.push("one", "two");
observableCollection
    .reduce(
        (result, item, index, collection) => {
            // result is actually the item
            // item is actually the item index
            // index is actually the observable collection
            // collection is undefined
            // The result array is actually provided through the callback context
        },
        []
    );

Hi @Andrei15193,

Nice work anyway! ...but:

You forgot about Model. The MVVM pattern requires to implement the Model facilities or it isn't MVVM really.

1. In all of the members of MV* patterns family the M[odel] is on first place and seems as a central of the world and MVVM isn't exception from that rule. The M acts as a single source of truth in the whole application.
2. What is model really?

• It answers to all of requirements of the application functional spec including all of business logic of the application;
• It includes both entities definitions (e.g., POJO or POCO classes) and entity manipulation services (stores, mediators, etc.) as well;
• The Model infra must support identity of entities. The typical entity interface is IModel, where T is the type of the id property;
• The good Model framework implementation may include a ValueObject pattern implementation to support immutable types, e.g., an id.
• All of validation rules must be declared on entities. Ideally validation rule should be decorator on property (e.g., @min(5) @max(10)). It's because the VM is only abstraction of the View or a state of the View;
• The Model infra must support undo/redo automatically (memento pattern);
• The good style is that Model (Service) represents a single point of asynchronous operations;
• You may see a model like as an independent part of the application. The good model should be [potentially] reusable, because it has no dependencies on View staff.

3. Various kinds of ViewModels:

• Application (or Navigation, or root-level) ViewModels. Those are ViewModels, which are subjects of composition. The lifecycle of such kind of ViewModels usually includes a sequence of following events: activating (usable to prevent navigation to component/page), activated, deactivating (to prevent navigation from the component, if some data not saved, for example), deactivated;
• Entity (or Object) Wrappers ViewModels. Those ViewModels are wrapping Model entities and provides entity instance to View with Model getter property. In addition, the abstract class ObjectViewModel<TModel> inheritors may provide implementations of the Commands like as "Save" or "Undo". The lifecycle of those VM's must include projection of the composable component, like as an InvoiceLineItemViewModel in front of InvoiceLineItemView (component).

4. An additional word about MVVM implementation. MVVM is a pattern. When we are talking about patterns, we are talking about separation of concerns. In other words, we expect from MVVM strong separation between its three subjects. So, to satisfy this requirement you need an engine to locate the View by ViewModel. It's also known as ViewModel-first approach. The good architecture is testable architecture. How can you test each layer of the application built on your framework separately (isolated)? E.g., how you test a VM without to involve the View and Model into the process? You need to use DI to separate VM from Model and Model from the Data Layer. So, you will be able to substitute various data providers for the Model, like as FakeDataProvider, RestDataProvider, or GQDataProvider.
5. Etc....

Anyway, your framework is very interesting as an initial point of the subject. I'll be very glad to talk (to discuss) to you, if you want.

The library exposes a single way of initializing an observable collection, which is great for most cases. On the other hand, there are situations where view models may need to expose a read-only observable collection and have specific methods for add, updating and removing items.

The library should expose two classes, ReadOnlyObservableCollection and ObservableCollection where the former exposes protected array mutating methods (push, splice, shift, unshift etc.) and the latter extends the former and exposes these methods.

In addition, the observable collection exposes an event that notifies observers when an item was added and allows a clean-up callback to be returned specific to that item, the callback is called when the respective item is removed. This will allow for safe event subscription/unsubscription for each item as it is add and removed from the collection through closures.