jacomyal/domino-v2-proposal

[deprecated]

👋 Hello!

I'm Alexis Jacomy, aka @jacomyal, a Front-End Engineer specialized in graphical rendering and data visualization.

I'm part of the innovative team at OuestWare, an agency based in Nantes, France. We specialize in developing web applications for data exploration.

As a part of my work at OuestWare, I'm the main developer and maintainer of sigma.js, an open-source library focused on efficiently displaying networks within web pages.

We also develop:

• Gephi Lite a web-based, lighter version of Gephi, the networks visualization and exploration software;
• Retina, a web application to share graph visualizations online.

Finally, I sometimes write on 🐘 Mastodon or on 🗒 OuestWare's blog.

Thank you for visiting, and let's connect!

domino-v2-proposal's Issues

Controller events data

1. I think that data in events is not unit tested
2. When emitting an event with data, data is not correctly passed to the listeners (function _execute here is fishy and provide for undefined data to emitter.

On the question of listeners' scope

Currently, this does not refer to the controller in event listeners. Is this by design or by mistake?

Implement domino#help method

Just have to follow @Yomguithereal already written unit tests.

[Idea]: properties fallback

Would it be useful to define a fallback value for some properties?

controller.registerProperty('prop1', {
  type: '?string',
  fallback: 'Hey, I am the fallback string!'
});

controller.update('prop1', false);

controller.get('prop1');
>>> 'Hey, I am the fallback string!'

Move the emitter to its own repository

It is a piece of code that might be very useful outside domino, so it might be useful to put it out, as djax and typology.

Types L70

Yo Dawg, explanation.

Types instantiation

It would be nice to be able to create types instances. An instance would be attributed to a given controller instance and it would be possible to register types through it.

Properties registration polymorphism

In old domino, properties would be stated thusly:

var d = new domino({
   properties: [
    {
        id: 'p1',
        type: 'string'
    },
    {
        id: 'p2',
        type: 'number'
    }
   ] 
});

So, for starters, we need a a posteriori low-level interface to deal with properties like:

d.addProperty({id: 'p3', type: 'number', namespace: 'x'});
// or
d.addProperty('p3', {type: 'number'});

And we could register properties likewise (considering namespaces also):

var d = new domino({
    properties: {
        ns1: {
            x: {
                type: 'number',
                description: 'a random number'
            },
            y: {
                type: 'string',
                defaultValue: 'Hello World!'
            }
        },
        ns2: {
            x: {
                type: 'number',
                description: 'This property is also x but is also namespaced.'
            },
            z: {
                type: 'object'
            }
        }
    } 
});

But now, what do we decide for polymorphism, that is to say, if we write something like the following:

var d = new domino({
    properties: {
        x: scalar
    } 
});

// or

d.addProperties('x', scalar);

I would advocate for property type, likewise:

var d = new domino({
    properties: {
        x: 'number'
    } 
});

// or

d.addProperties('x', 'number');

Extending domino.name definition?

With . and :.

Make gulp task being executed sequencially