andrei15193 / react-model-view-viewmodel

A library for developing React applications using Model-View-ViewModel inspired by .NET

Andrei15193's profile

Hey, how's it going? Hopefully all is good and if not, what is life without a little challenge?

I'm a software developer since 2013, that's when I got my first job, starting with .NET and SQL for the first 6 years and afterwards added ReactJS to my toolbelt, some DevOps here and there.

I do pet projects apart from what I'm doing at work. I like to have control over what I learn rather than wait for a project where I can learn what I am interested in. Obviously, I wouldn't be able to apply what I learn at the level of a multi-person project with allocated time, but it does provide useful experience later on to help the work project out. I've done this already on multiple occasions.

Besides software development, I read books, mostly non-fiction, related to psychology or phylosophy. The two go hand in hand to a certain degree. Watch TV shows (Pickle Rick.. YEAH!), and movies when I get the time.

I am maintaining two open-source projects, one of the is react-model-view-viewmodel and the other is CodeMap along side an associated project EmbeddedResourceBrowser for it. If you are interested, check them out.

If you want to collaborate or reach out to me, you can look me up on the various social media platforms, if it's something more professional use LinkedIn, otherwise you can send an e-mail or reach out on Facebook or Discord (yes, I am intentionally not leaving any links to these here, you'll have to use your search skills).

react-model-view-viewmodel's Issues

Extend ObservableCollection Features

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.

What's about the Model?

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.

Observable Collection Reduce Improper Parameters

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
        },
        []
    );