Sparkx

Sparkx is an abstraction over Redux and UI Router.

What problem did it solve?

While creating an application, a developer has to take care of a lot of things. State management (initialisation, updation, deletion), routing, API calls, components, forms, validations, and performance, etc. And often for each one of these, we use a different library. Like Redux for state management. Router of choice depending on the tech stack. axios or some other third party library for API calls and some tooling to ensure performance. And each one of these may require the developer to manage multiple files (like action and reducer for Redux state management). So, even for a simple task of added a few fields, it often happens that multiple files needs to be changed. Making it harder to maintain over time. Also, the logic is split into multiple files violating the separation of concerns principle.

Moreover, while writing unit tests, we use to test these separately thus adding a lot of testing baggage. And it is hard to tell what actually broke, if one of your test case is failing, as it may be used in multiple flows. Many try to solve this using integration tests and having some discipline around their developmental flows. But these only adds to maintenance cost of the codebase and also slows down the developer.

Even creator or Redux agrees that you should not need to touch three files for simple feature. And says that the developer should decide if the tradeoff are required. However, while setting up a new project, it is hard to guess how complex it would get. We would like it to scale infinitely to a big corporate level, but at the same would like to iterate fast. Now these two statements are conflicting each other. And rewriting a large app to a new tech stack is pain.

How did it solve it?

By putting clever abstractions, we can overcome this. We can have most (if not all) of the benefits of using Flux architecture, while at the same time have a good separation of concern provided by a MVC architecture. Sparkx provides these abstractions.

It was inspired by Angular and so it borrows most of its concepts and design patterns from it, while at the same time uses Redux for state management. This makes Redux , axios and UI Router its obvious allies. However, it aims to be transparent in everything, so that when certain abstractions doesn't fit your use case, then you can easily fallback to naive or vanilla way of doing things. So, that you, as developer, won't have to fight it when it doesn't work.

It doesn't provides a view. But, we aim to write adaptors for each view separately. Currently, we have done it for React. So, the learning curve should be small as well.

It takes an opinionated framework approach. Just like Angular, you have controllers and services.

• Your models are automatically wired to your controllers as variables, and as props to your view (React components).

• You can create a nested route and this will also create hierarchy in your models. But your child views will have read only access to their parents' models. Making it possible to easily lift the state up (if a need arises).

• Models are divided into two parts. Global and local. While anyone can read and update the global scope. Local scope can only be updated by that controller only.

• Your services are singleton objects and are mean for API calls, store data or any other shared logic.

• It also clears the model when you move out of that view.

These 5 points are the only things that you need to know to start writing an app.

Features

Following is our bucket list of features that we aim provide.

• Application state management

• Immutable state

• Hierarchical state

• Routing with nested routes, transition hooks and lazy load

• Support for hash and browser history API routing

• Typed

• Singleton services

• Support for React

• Support for Preact

• Support for Lit Element

• Support for Vue

• SSR

• Pre-rendering

Roadmap?

We haven't planned anything yet. We are still in beta, trying things out. But there are few things that we have decided.

1. We don't want to become a monolith. A developer should easily understand what is happening underneath the abstractions.

2. We don't want to make breaking changes.

3. The contract should be same irrespective of the view library used. This means that the node packages we use should also be view agnostic.

4. The services we write should also be usable across application irrespective of the tech stack.

5. Typed and well documented.

6. Meaningful test cases with decent coverage.

7. Have a low bundle size.

And it goes without saying, PRs and suggestions are welcome!