soney / constraintjs Goto Github PK

<span class="poop">Howdy!</span>
<script src="cjs.js"></script>
<script>
var color = cjs("blue");
var text = cjs("Good bye!");
var poops = cjs.$(".poop");
poops.css("color", color);
poops.text(color);
</script>

Expected: blue text saying "Good bye!"
Actual: blue text saying "Howdy!" and an uncaught exception

I was thinking about a nice alternative to check_on_nullify.

check_on_nullify avoids invalidating the dependant constraints when the value of a constraint didn't changed. This may be very important when the processing of a constraint is quite resource consuming and thus should be avoided as much as possible.
However it requires the constraint to be re-evaluated, possibly heavy too, on each nullification while it may not actually be used.
It also mean that it is the responsibility of the parent constraint to know that the dependant constraints are resource consuming and should not be invalidated for nothing.

Here is a simple example:

var num = cjs(0);

var sign = cjs(function () {
    // heavy stuff
    console.log('compute sign');
    return num.get() ? num.get() / Math.abs(num.get()) : 0;
});

var signStr = cjs(function () {
    // heavy stuff
    console.log('compute string');
    return {
        '-1': 'negative',
        '1': 'positive',
        '0': 'null'
    }[sign.get()];
});

num = cjs(-5);
signStr.get();
// compute sign     -> OK: -1
// compute string   -> OK: 'negative'

num.set(-8);
signStr.get();
// compute sign     -> OK: still -1
// compute string   -> Whoops ! Recomputed for nothing!

I was thinking of a compromise.
There could be one more state to a constraint:
1- valid
2- invalid
3- maybe
A constraint could keep a list of its 'invalidators': the constraints responsible for its invalidation.
When a constraint is invalidated but not checked it puts its children into the 'maybe' state instead of invalidating them definitively.
When an invalidated constraint is computed, it checks if it really changed. If it did, it puts its children in the state of definitely invalid. However if it it didn't, it removes itself from the invalidators of its children. If the children has no invalidators anymore, it switches back to valid and do the same to its children and etc.
When a 'maybe' constraint is requested, instead of computing itself, it first checks its 'invalidators'. If during the process it switches to the invalid state, it computes itself. If not, it returns the cached value instead.

When a given css property is a number, jquery automatically add the 'px' suffix.
Exceptions are (from jquery source code):

{
        "columnCount": true,
        "fillOpacity": true,
        "flexGrow": true,
        "flexShrink": true,
        "fontWeight": true,
        "lineHeight": true,
        "opacity": true,
        "order": true,
        "orphans": true,
        "widows": true,
        "zIndex": true,
        "zoom": true
    }

I kind of like this behavior... And I guess if jquery does it, it is safe. I think cjs should do the same.

Another arguments in favor of this functionality:
The behavior of cjs regarding this depends of the html doctype balise on top of the page it is included... Yeah I just lost 2 hours trying to understand why the exact same code didn't work anymore in a (almost) similar condition.

MapConstraint breaks when created with a value parameter containing "length".
The reason is that it uses the each function to create the options.keys and options.values arrays from options.value, but each treats any object containing a "length" property as an array.
As a result option.keys ends up with integers ranging from 0 to options.value["length"] and option.values is filled up of undefined.

"It seems when you change the eye radius slider, the container for the sliders can shrink when the eyes shrink, which makes the slider smaller and causes the slider to move more which makes the eyes shrink even more. It races to the min value in a blink. Giving #ex3 a minimum width seems to fix it."

The function startsAt(state_name) does not work propertly. When you create an state machine and sets an state name, then if is called getState() of the FSM it returns the first state added and not the start state.

It seems there is absent parameter in signature of bindCSS and in the corresponding example inside DOM Bindings document.
In the former case there is no reference to the processed DOM element:

.bindCSS(attr_name,value) — set a CSS attribute of the DOM obj.

In the latter case CSS style property (attr_name) is absent:

var binding = cjs.bindCSS(my_elem, bg_color); // my_elem has a red background

There is a typo in the example for cjs.bindCSS documentation:

cjs.bindCSS(my_elem, ''background-color', color);

Moreover it seems that the second signature of bindCSS should be bindCSS(element, key, value) where element is reference to the DOM element

I can't seem to call .lt() .le() .gt() .ge() on a cjs variable

White text on black background is almost invisible for some users

suggestions: change color scheme, font size

Protecting an internal constraint is I guess quite easy: one only have to provide a 'public' constraint on its 'private' constraint instead of the 'private' constraint itself. But the setter of this public constraint is still callable and one may still re-set it.

At the opposite, a view on the 'private' constraint would be only get-able. The idea is that it reacts and can be used exactly as any other constraint. It would of course still be invalidated by its parent constraint... But one cannot change directly its value.

Thus, one could expose a bunch of protected constraints as an interface.

It would be nice to be able to create a MapConstraint of a MapConstraint..

For example:

var cjsMap = cjs({
    '1': 'a',
    '2': 'b'
});
var other = cjs(cjsMap);

console.log(cjsMap.item('1')); // a
console.log(other.item('1')); // undefined :(

ConstraintJS embeds a lot of different functionalities such as templates or fsm.
All these functionalities make the library quite big while a user may only need some part of it.

I think it would be great to reorganise a bit the library in modules, e.g. ES6 modules that is the upcoming standard and that can already be used using babel.
The tradeoff of this approach is the requirement for a compilation process but constraintjs is already compiled.

This has two main advantages:

1. Cleaner and easier to maintain.
2. One can import only the parts he needs.

Now I actually already started to work on this for my personal use so I can submit a push request if I succeed in doing so.
I have two questions however:

1. None of my previous push requests have ever been merged. Is there any chance this push request could be merged or should I just not worry about it?
2. Is this (great) project still maintained at all? If it is not there is no need for me to make sure that future commits from this side can easily integrated in my fork.