@idoros
add iterate function to data types (complex, list, map)

Make sure that all mutating operations on Maps and Lists fail and issue a warning to the console.

extending basic universal data types (date, url, email, position etc.) usually don't make much sense.

see here

the typings for list reduce define the prevValue of the reduce function as the generic type of the list

provide instance data in error messages, for example in Moving mutable private state instances between containers

• define-enum.js
• es5-map.js
• generic-types.js
• list.js

with project description

should we support defining a field of type BaseType ?

currently it results in

Uncaught Error: Field "a" in the data class "State" is not a descendant of Type.

create a mutable instance that instead of wrapping data it refers to a function that computes that data.

the use case is for a user to wrap a mobx @computed function that returns complex data, so that different parts of the result can be destructured and tracked separately.

Also, it can be used as a reference an existing observable data without cloning it.

• support user-defined types
• support List
• support Map
• add helpful error messages

This optimization seems necessary for generic types, as a runtime reference creates a new type instance every time.

Most glaring example:

const list = Mutable.List.of(core3.String)();

So every time this code is called (imagine a loop... 😢 ), you'll create a new type definition.

perhaps only for derived types (of, nullable, withDefault etc.)

right now maps are not tracked correctly

toJSON() function should return a subset of toJS() only without fields that contain unserializable data (NaN, functions...)

any place there is a call to MAILBOX.something and an errorContext is defined in the scope it should be part of the message (incl. tests)

found example: List constructor

  if (!errorContext) {
    errorContext = _List.createErrorContext('List constructor error', 'error', options);
  }
  const report = _List.reportDefinitionErrors(options);
  if (report) {
    MAILBOX.error('List constructor: ' + report.message); // <--- no error context!
  }

Use-cases:

• generic parameter (e.g. EventHandler<void>)
• method parameters schema

how does returning void differ from returning undefined?
Or is this for code-sense-foo?

void is a special type that only matches undefined, so when the type signature is void, you expect the runtime value to be undefined.

instead:

expect(instance instanceof ClassName).to.equal(true, 'message');

should be:

expect(instance).to.be.instanceof(ClassName, 'message');

need to add a dynamic type that can accept any type and be assigned to any type

including how to use in react

from src/list.js :

static of(subTypes) {
        //TODO: remove this when transpiler shenanigans are over
        if (arguments.length > 1) {
            subTypes = Array.prototype.slice.call(arguments);
        }
        return this.withDefault(undefined, undefined, { subTypes });
    };

@tobich

We seem to lack efficient way to say

if(Mutable.isMutableInstance(instance)) {}
if(Mutable.isMutableType(Type)) {}

there are lots of places which try to do it in various ways

• equals() function for data-driven dirtyness (with pure js value or Mutable value as argument)
• hasChangedSince() function for version-driven dirtyness (just like we do now)
• advance revision automatically on every change to Mutable property (TBD)

Seem like there is no deep validation for Mutable.Map values. That is mean that if value is of some complex type then you could use any object for it. I provide unit tests for this issue. You can find them in maksym/provide-unit-tests-for-map-type-checking branch

when assigning a complex value (user-defined object) to a union field that should accept this value, the assignment fails.
the error seems to be in $assignField at object.ts file:

const typedField = isAssignableFrom(MuBase, fieldDef);
// for typed field, validate the type of the value. for untyped field (primitive), just validate the data itself
if ((typedField && fieldDef.validateType(newValue)) || (!typedField && fieldDef.validate(newValue))) {

typedField is false although the union contains a typed type
there are two separate bugs here:

1. for now union should return true for isAssignableFrom(MuBase, fieldDef)
2. the check should depend on the value (or completely simplify the validation mechanism)

reported by @talh78

Typescript offers tslib, maybe we should use it.

should we leave it, should we fail-fast? decide by version?

I have the following code

function changeCollection(rawData:List<RawData>): List<Data> {
    let filtered:List<RawData> = rawData.filter((value)=>  true/** some condition */)
    console.log('Wo: ',  filtered) // looks good
    let mapped:List<Template> =  filtered.map(rawToData) // returns [] instead of List<Data>
    return mapped;
}
function rawToData(val:RawData):Data{/*Impel*/}

there are many references, the best one is Chapter 3 of Effective Java Programming Language Guide By Joshua Bloch.

These methods will allow using Mutable objects as keys in hash-based data structures.

Hello,

Is this library still active?

My name is Shaun Wallace, I am a PhD in HCI at Brown University.

We are finishing up a new JS library and were hoping to use the "mutable" name for the library. Since Wix's library has not received updates in 3 years, nor any new comments would we be able to use the name "mutable" for our repository? If not no worries. :)

• our new library is not similar to or takes any code from Wix's mutable library.

For example:

// this.props.menuItems: MenuItem[];
// i.e. it is a typorama instance and lodash won't work
var selectedItem = _.find(this.props.menuItems, { id: this.props.selectedItemId });

One does this error very easily and it is not always immediately clear what's wrong. :-(

spoon lodash to throw error when it gets typorama object (just in development?)

mobx and mutable $assignField ignore NaN != NaN and causes reaction loops.

maybe make mutable reject NaN value (can't think of a reason to accept), and escalate warning

The project's API has changed since the move to mobx, and also the project's concept got more precise.
We need a new readme file and some API documentations.

Currently the sort() method does not change the list but returns a new one.
This seems inconsistent with similar methods like reverse and splice

Why is that?
@nadavwix

The whole validation mechanism is starting to be messy. We need:

• unified API for validate* functions. (There are true/false responses, null or value, Error or value and maybe more).
• ability to easily chain/extend atomic validations
• channel for passing errors (which, by default, would throw() 'em, but could be wired to some logger instead)
• mechanism which makes sure that any validation failure is consumed (we have situations, when failed validation just passes silently, without any message)
• error/warning/message builder/resource manager to have a single source for all messages

Proposal by @tobich

Unified validation API

Validating function validate(value) returns one of the following

• the original value (or its replacement, such as wrapped value) if the validation went fine
• instance of Error object (or its extension) if there was error
• VALIDATION_SKIPPED object value if the validation couldn't be performed (useful for validation chaining)

Calling validating functions

// module validationUtils.js
export function validate(value, context, validators:Array<Function>, callback:Function) {}

Runs value through the chain of validators. If a validator returns Error, the whole function passes the error to the reporter pipe and returns the error as return value. If VALIDATION_SKIPPED is returned by a validator, it is ignored and next one is called. If all validators have passed or been ignored, the optional callback is called with the value as parameter and its return value is returned.

Error reporting channel

// module errors.js
export function report(err:Error) {}
export function setHandler(handler:Function)

validateProp function of Map doesn't access value = null

@arnonkehat says:
enums not properly handled in stack
I tried use an enum in a dropdown, and could not use its values as the dropdown items. talk to me if you want to see what I was trying to do.