Plugin System
RocketJump help you reusing you RjObject logic using an advanced plugin system.
You can use write your own plugins ore use some good plugins provided by the library.
To write a RocketJump plugin you should use the rjPlugin
function, it accepts
the same parameters of rj
function except for effect
, mutations
and computed
theese options are only allowed in the rj
functions.
To use a plugin pass them to the rj
function before the config object.
#
Your first pluginTry to explain the concepts above with a basic example.
You a write a simple RjObject to handle a todo list:
You have to write another RjObject to handle for example a list of users.
You notify that the updater
to append new a item to a list of todos or user
is the same.
First, extract updater logic to an action creator an handle them with composeReducer
:
Now it's time to make it reausable extract it as a RocketJump Plugin!
Now everytime you need to insert an item you can your awesome appendPlugin
!
#
Compose pluginsOne of the wonderful property about plugins is that you can compose them.
For example you are very entusiast about plugins and you also write
the removePlugin
to remove an item from a list and the updatePlugin
to update
an time from a list.
You can use all of them with the rj
function:
Or you can compose plugin toghter and make an unique plugin!
You can compose plugin togher with no limitations, only you fantasy is the limit!
#
How does composition work?Consider the following example
The composition order goes from top to bottom and from left to right. Hence, in our example, we have the following composition order: config R > config O > config C > config K
.
#
Different composition strategiesDue to the wide variety of available configuration properties, it is not possible to define a global composition strategy. Instead, we can describe some composition strategies which describe how different properties are composed
#
Chain propertiesChain properties are actions , selectors, effectPipeline
Chain properties are so called because they are functions that are invoked in chain (i.e. the output of the previous one is the input of the second one) in composition order at composition time. The argument of the first call is the default value. At the end, the RocketJump Object will contain only the output of the last call.
In our example, let's pretend that all the four config objects (R, O, C, K) define the actions property. Composition works like this:
- the default action bag is generated
- the actions transform of
configR
is called with the default action bag as parameter, and its output merged with the default action bag to producetempActionBag1
- the actions transform of
configO
is called withtempActionBag1
as parameter, and its output is merged withtempActionBag1
to createtempActionBag2
- the actions transform of
configC
is called withtempActionBag2
as parameter, and its output is merged withtempActionBag2
to createtempActionBag3
- the actions transform of
- the actions transform of
configK
is called withtempActionBag3
as parameter, and its output is merged withtempActionBag3
to createtempActionBag4
- the actions transform of
tempActionBag4
is the final action bag
#
Recursive propertiesRecursive properties are reducer, (composeReducer), effectCaller
Recursive properties are so called because they involve runtime function composition: the final value is a function which is the mathematical composition of the functions defined in the merged configurations in composition order.
composeReducer here is put in parenthesis because it is not involved directly in composition, being squashed onto the reducer property before composition starts (i.e. with respect to composition, there is no composeReducer property, but only reducer, which contains also all the composed reducers)
Let's pretend that all the four config objects (R, O, C, K) define the reducer property. Composition works like this:
- the default reducer is generated
- a new reducer is created by transforming the default reducer as stated in
configR
to createtempReducer1
- a new reducer is created by transforming
tempReducer1
as stated inconfigO
to createtempReducer2
- a new reducer is created by transforming
tempReducer2
as stated inconfigC
to createtempReducer3
- a new reducer is created by transforming
tempReducer3
as stated inconfigK
to createtempReducer4
tempReducer4
is the final reducer
Let's pretend that all the four config objects (R, O, C, K) define the effectCaller property. Composition works like this:
- the default effectCaller is generated
- when the user triggers an effect run, the following things happen:
- the
effectCaller
specified inconfigR
is called, with itseffect
argument set to a fake effect function - when the fake effect function is called with
...args
, theeffectCaller
set inconfigO
is called with...args
and with a second fake effect function - when this second fake effect function is called with
...args
, theeffectCaller
set inconfigC
is called with...args
and with a third fake effect function - when this third fake effect function is called with
...args
, theeffectCaller
set inconfigK
is called with...args
and with a the default effect caller as itseffect
parameter
- the
#
Merged propertiesMerged property is only combineReducers
Merged properties are merged using plain object assignment in composition order.
#
Overwrite propertiesOverwrite properties are takeEffect, name
Overwrite properties are not merged, the last configuration in composition order defining it wins.
addSideEffect
#
Finaly addSideEffect
collect the list of result Observables using the composition
order describe above and finally create an unique
Observable using the RxJS merge function.