If you can understand the ideas in $mol and create few applications, the framework you were working on before will make you feel nauseous and want to rewrite the whole code.
Empty your mind
The more development experience you have, the harder it is for you to accept new concepts. Your brain will resist, at the very least you may start spewing your knowledge into chat or comments. As a result, you won't be able to master a simple enough framework. Better try to absorb information without an internal censor. The censor can be turned on when you have a whole picture of $mol. $mol is hard, not because it's hard, but because it doesn't look like what you're used to.
What is $mol?
$mol - does not have any core. $mol is nothing more than a set of isomorphic modules, well docked to each other. Each module performs its function well. The modules can be used anywhere, including other frameworks. Some of them are published in npm.
Most modules are designed to be deadly simple. Some modules have a readme.md file, not all of them need it. It is good practice to look at the source code, most often you will not see more than 100 lines of code. Yes, the repository has a large number of folders, few hundred of them. It may be time to reorganize them, but overall it is not a problem for application development.
Developers tend to pay a lot of attention to the richness of the framework ecosystem when choosing what to use for the frontend. $mol has enough modules to cover most needs. The missing ones are easy to build on top of existing modules. And of course you can get package from npm.
Modular system MAM - Mam owns language-Agnostic Modules
MAM is a modular system in which $mol modules live. The agnostic module is the directory with the files that implement it. The module is primary, and its implementation is secondary. MAM is a set of rules/restrictions/principles that allow us to turn our code into LEGO cubes with minimal effort. The MAM implementation, builds the code described by these rules into several bundles.
MAM can be called a methodology, but there is no specification. Only an implementation in one of the $mol modules and a few articles.
You should start with MAM. Clone the repository, build it, run it, understand how to create and use modules. And then learn the reactivity system.
Reactivity
If you know how Mobx works, then you already have an understanding of how the reactivity system in $mol works.
Unlike the control flow architecture, $mol implements a data flow architecture. An application is defined as a set of classes with reactive properties (a method with a decorator). Each property is defined as some function of another property (and properties of other classes too).
When reactive properties are called, they remember which properties they are accessing - a dynamic dependency graph is built. And they also cache the result of their values.
When some property changes its value, all of its dependencies become obsolete. If you call a obsolete property, it will force all dependent and obsolete properties to be updated. If you call the actual property, it will return the result from the cache.
In this way the whole application at the execution stage represents a huge tree of dependencies, with a special property at the root of the tree, which in case of invalidation would actualize itself automatically. And as any property always knows, whether something depends on it or not, then it is given a simple and reliable mechanism of controlling lifecycle of objects - they are created when dependence appears and are destroyed when nothing depends on them. This solves two fundamental problems: resources leaks and cache invalidation.
The reactive system works at all levels of the application, not just in the view.
View components
When you understand how to use the reactivity system, you can move on to creating view components.
$mol components, fully divided into five parts:
1) Declarative description of the component interface and data flow(required, others are optional)
1) Imperative behavior of the component
1) Styles
1) Localization
1) Tests
There is a basic view class with properties like events, attributes, children, etc. - It acts as a wrapper on the DOM element. When any of its properties become not actual, the reactive system automatically triggers its actualization and this updates the element in the DOM-tree.
Custom components, inherited from a base class and customize its layout, behavior, styles. The reactive system ensures that the DOM-tree is updated in a point-by-point and optimized way when the data on which a component depends on changes.
The hardest part here is learning the view.tree. This is the language in which the component interface and data flows are described. The difficulty is that it is not familiar. We're used to something similar to html, but this is more of a typescript interface.
With view.tree we say:
what our component is called
which component it inherits from
what components it owns
how these components are composed in its children
what states the component has
which data flows are linked to components and states
The view.tree builder turns the description into a typescript class.
Overview
Disclaimer
If you can understand the ideas in $mol and create few applications, the framework you were working on before will make you feel nauseous and want to rewrite the whole code.
Empty your mind
The more development experience you have, the harder it is for you to accept new concepts. Your brain will resist, at the very least you may start spewing your knowledge into chat or comments. As a result, you won't be able to master a simple enough framework. Better try to absorb information without an internal censor. The censor can be turned on when you have a whole picture of $mol. $mol is hard, not because it's hard, but because it doesn't look like what you're used to.
What is $mol?
$mol - does not have any core. $mol is nothing more than a set of isomorphic modules, well docked to each other. Each module performs its function well. The modules can be used anywhere, including other frameworks. Some of them are published in npm.
Most modules are designed to be deadly simple. Some modules have a readme.md file, not all of them need it. It is good practice to look at the source code, most often you will not see more than 100 lines of code. Yes, the repository has a large number of folders, few hundred of them. It may be time to reorganize them, but overall it is not a problem for application development.
Developers tend to pay a lot of attention to the richness of the framework ecosystem when choosing what to use for the frontend. $mol has enough modules to cover most needs. The missing ones are easy to build on top of existing modules. And of course you can get package from npm.
Modular system MAM - Mam owns language-Agnostic Modules
MAM is a modular system in which $mol modules live. The agnostic module is the directory with the files that implement it. The module is primary, and its implementation is secondary. MAM is a set of rules/restrictions/principles that allow us to turn our code into LEGO cubes with minimal effort. The MAM implementation, builds the code described by these rules into several bundles.
MAM can be called a methodology, but there is no specification. Only an implementation in one of the $mol modules and a few articles.
You should start with MAM. Clone the repository, build it, run it, understand how to create and use modules. And then learn the reactivity system.
Reactivity
If you know how Mobx works, then you already have an understanding of how the reactivity system in $mol works.
Unlike the control flow architecture, $mol implements a data flow architecture. An application is defined as a set of classes with reactive properties (a method with a decorator). Each property is defined as some function of another property (and properties of other classes too).
When reactive properties are called, they remember which properties they are accessing - a dynamic dependency graph is built. And they also cache the result of their values.
When some property changes its value, all of its dependencies become obsolete. If you call a obsolete property, it will force all dependent and obsolete properties to be updated. If you call the actual property, it will return the result from the cache.
In this way the whole application at the execution stage represents a huge tree of dependencies, with a special property at the root of the tree, which in case of invalidation would actualize itself automatically. And as any property always knows, whether something depends on it or not, then it is given a simple and reliable mechanism of controlling lifecycle of objects - they are created when dependence appears and are destroyed when nothing depends on them. This solves two fundamental problems: resources leaks and cache invalidation.
The reactive system works at all levels of the application, not just in the view.
View components
When you understand how to use the reactivity system, you can move on to creating view components.
$mol components, fully divided into five parts: 1) Declarative description of the component interface and data flow(required, others are optional) 1) Imperative behavior of the component 1) Styles 1) Localization 1) Tests
There is a basic view class with properties like events, attributes, children, etc. - It acts as a wrapper on the DOM element. When any of its properties become not actual, the reactive system automatically triggers its actualization and this updates the element in the DOM-tree.
Custom components, inherited from a base class and customize its layout, behavior, styles. The reactive system ensures that the DOM-tree is updated in a point-by-point and optimized way when the data on which a component depends on changes.
The hardest part here is learning the
view.tree. This is the language in which the component interface and data flows are described. The difficulty is that it is not familiar. We're used to something similar to html, but this is more of a typescript interface.With
view.treewe say:The view.tree builder turns the description into a typescript class.
Next
In the next section we study MAM