mtmr0x/nucleo

🏋️‍♀️ Nucleo is a strongly typed and predictable state container library for JavaScript ecosystem written in TypeScript

nucleo's Issues

Null and/or optional values in Nucleo objects

We discussed about how to treat possible optional fields and/or null fields and how Nucleo can work with that.

Right now Nucleo must receive data as expected, has no optional field (which is actually really coherent to its purpose) and does not accept null as value or as possibility.

Making it easy, we have to decide two main things here:

Should Nucleo have optional fields? Why? And if yes, how?

Should Nucleo have a way to treat or understand somehow null values? Why? And if yes, how?

NucleoFunctionType

I've missed of a function type to complement a given data model.

Roadmap file

Well, this is going to be useful to have, organised by each patch in a simple way to organise the project needs.

Probably the best approach is how they're doing in Deno project, a simple file in the root of the repository.

https://github.com/denoland/deno/blob/master/Roadmap.md

Custom primitive types

As quoted in #9, Nucleo needs to give freedom to primitive/scalar types. This way Nucleo can receive contracts like this:

const ageRule = (value) => {
  return value < 100; // you defined here that age can not be higher than 100
}

const userType = new NucleoObject({
  name: 'user',
  fields: {
    name: NucleoString(),
    age: NucleoString(ageRule)
  }
});

The age field will be validated by the rule the user sent.

It will demand:

• Refactor in Nucleo Pimitive type
  • These types must be a function
  • Inside these functions must validate if the received argument is a function
  • nucleo primitive type must store in its scope the validator to be ran
• Lawyer must be refactored to validate the field rule alongside with its validations

Custom primitive types for verifying a specific model of something

In discussion with my friend Hugo Bessa, we spoke about how could I make sure a ISO date would be always a ISO date and creating other types might not be a great idea but what about my primitive type be custom somehow?

Examples

Custom primitive number type

I know it's a number, but I can create rules for this number don't be greater than x or non-zero values

Custom primitive string type

It must be a string, but is a specific type of string, as a only numeric string or not having spaces, validated by a regex, for example.

Avoid cyclic objects

I really don't know if it's a good idea or not, but for now I would say to avoid entering cyclic objects in store for avoiding n problems.

Lawyer function

Tasks

• documentation at Wiki
• verification for non primitive or non Nucleo Object types
• recursively call lawyer for Nucleo Object Types

Tests

• Recursively call lawyer for NucleoObjectType fields
• verify data types
• verify fields not presented in contract

Javascript error when you call the cloneState of a non-existent contract

When you call the cloneState method of a non-existent contract instead of receiving a undefined value, the javascript throw a TypeError as a invalid code.

So, as I said before, when you ask for a contract non-existent we need to receive something that does not stop the application, and that we can manipulate.

Make all validations and fixes for update method

update method is still quite bugged and not well tested. Improve tests and validations for make sure update is mature.

be able to change only one data level of data in store

Imagine the user want to save one specific field only and there is no need to re-save others. Could dispatch be able to identify it somehow and save a single data?

Or maybe a update function responsible for that?

considering the store value for userTest is:

{
  userTest: {
    name: { firstName: 'John', lastName: 'Smith' },
    age: 20
  }
}

If we run:

update('userTest')({ name: { firstName:  'Joe' } });

we get this result:

{
  userTest: {
    name: { firstName: 'Joe', lastName: 'Smith' },
    age: 20
  }
}

Make subscribe send alongside with contractName, the new data in that state

Task

When a listener be executed from inside Nucleo, increment in the object the new data being stored as copy.

Checklist

• Make the object copy inside indexSearch;
• Increment the subscriber arguments the data;
• Send data to subscriber
• Enhance documentation for subscribers and listeners, explaining the flow

Can't update contract with `false` values.

When you call a update function, and pass false values like:

• Empty strings, of string type
• zero, of number type
• false, of bool type

These values doesn't update the store, and return OK with the supposed new values.
When this situation happens, was verified in the indexSearch, on rec and save methods inside dataReflection that, the validation of these new values use a conditional OR in javascript used like || and this don't let pass those false values, as said before.

NucleoObjectType

Task

Every object in Nucleo must be a Nucleo Object Type.

Checklist

• Create class to instance objects
• Make store creation validate every object as NucleoObjectType
• Lawyer must understand instances of NucleoObjectType

Primitive Types architecture

Task

Primitive types must be their architecture well defined for be able to storeTree assure the store contracts are aligned

Tasks

• Define types names
• Define object types architecture considering their name and functionality for comparison with the provided data from the dispatcher

Remove support for NucleoFunction

It is not returning the `newStore` in the dispatch or update method

Well, the problem consist in:

1. I try to use the update method, something like -> const user = update('user')({ name: { firstName: 'Robert' }});
2. I receive status "OK"
3. Instead receive newStore inside data value, as showed on documentation example:

{
  status: 'OK',
  errors: [],
  data: {
    name: {
      firstName: 'Robert',
      lastName: 'Nor'
    },
    age: 27
  },
}

I receive the same data, that I used into update method as a parameter, in another words, I receive

{
  status: 'OK',
  errors: [],
  data: {
    name: {
      firstName: 'Robert',
    },
  }
}

What about create an Enum type?

I've been thinking about create some immutable entries in some contract fields, what you guys think about create an Enum type that can be used by the contracts?

Contracts

Task

Contract is the Object Model for creating NucleoObjects. Creating the store, every object passed must be a valid contract created with NucleoObject;

Checklist

• Contracts must be passed as Objects;
• Contracts must have exclusive names. This must not be allowed to create 2 contracts with the same name;
• Creating store, the contracts must be validated if it's instanceof NucleoObject;

Tests

• You can't create two contracts with the same name per store
• Every contract must be instance of NucleoObject
• Creating the store and generating contracts, dispatch and subscribe must be returned

Create NucleoList class

We should be able to create lists of NucleoTypes and Lawyer function must validate it.

checklist

• Create the instance file with it's values
• Create the validation in lawyer for NucleoList instance
• Create the validation in lawyer to each value type in provided NucleoList

Tests

• Store creation with contract containing a NucleoList of NucleoString
• Store creation with contract containing a NucleoList of NucleoObject
• Dispatching data to it and validating wrong values
• DIspatching data to it and saving updated values

Improve NucleoList type tests

Task

Improve NucleoList tests, exploring possible flaws using update method

Checklist

flaws tests

• try to update a list with primitive values
• try to update a list with NucleoObject values
• try to update values to a list not according to the list primitive type expected
• try to update values to a list not according to its expected NucleoObject type

Clone method - a immutable way to get references from store

The Nucleo memory usage in saving data and sending information to listeners makes it possible, the only thing that is necessary to discuss and understand is how to make it and still provide performance and simple code.

Today we have:

update -> validations -> index state search with state clone -> save

In index state search with state clone is possible store another copy that is easy to consult and can be send to listeners as new reference.

Overall clean up in Lawyer

Lawyer is quite complex and tricky to understand, there is for sure a better way to make that code be better.

Weird behavior in dispatch error in comparison to update error

Dispatch is returning an error and it's not predictable considering how update works. For better error treatment, dispatch should return an error object for the developer treat errors nicely

Store and Store Tree creation

Description

It must create the storeTree and the store objects.

Tasks

• storeTree architecture;
• save storeTree in memory;
• store architecture;
• save store in memory
• Have a consultable function for the store || or store only inside the dispatcher function scope?
• Subscribe listener to the store events update

Questions

• Do store start without its contracts if not provided initial state?

Improve documentation for Nucleo API

Checklist

• NucleoObject;
• NucleoList;
• NucleoString/NucleoNumber/NucleoBoolean;
• createStore;
• dispatch;
• update;
• getStore;
• subscribe;
• contracts;

Unsubscribe functionality

Having subscribed as listener, it should provide a way to unsubscribe that listener.

• Callback function in subscribe
• Performance tests for solution
• Unsubscribe unit tests
• Update documentation

PR: #33