erichenry / interfacejs Goto Github PK

leave a short paragraph explaining why I decided to create this library.

Right now the create() function returns an interface object. That interface object currently has the implement() function as a method. This allows someone to create an interface object then use that object to create other objects that implement the interface.

By doing it this way you can define an interface as its own module and import that module where ever you'd like in your app to create new objects. This is the current implementation.

example

/** personInterface.js **/

const Interface = require('InterfaceJS');
module.exports = Interface.create('person', {
    nickname: 'string',
    age: 'number',
    greet: 'function',
});


/** index.js **/
const personInterface = require('./personInterface.js');

let melanie = personInterface.implement({
    nickname: 'mel',
    age: 28,
    greet() { return `Hi, I am ${this.nickname}`; }
}); 

melanie.greet(); // -> Hi, I am mel

The other way is for implement() to be a method on the Interface library. Having the function be a method would keep all functionality within the library. Therefore you would need to import its functions to do what you specifically wanted. The benefit of this would be consistency in usage. If you wanted to do anything regarding interfaces you would have to use the library. However this almost guarantees boiler plate code, which is definitely a pitfall.

In the following example a user would have to have the interface to pass to the interface object as well as the implementing object to the interface method.

Example

/** catInterface.js **/

const Interface = require('InterfaceJS');
module.exports = Interface.create('cat', {
    fur: 'string',
    speak: 'function',
});

/** index.js **/
const Interface = require('interfaceJS');
const catInterface = require('./catInterface.js');

let kitty = Interface.implement(catInterface, {
    fur: 'taby',
    speak() { return `Meow meow meow, I am a ${this.fur} cat`; }
});

kitty.speak(); // -> Meow meow meow, I am a taby cat 

Right now, the implement() function is a method of a created interface object. This needs to be refactored to be part of the interfaceJS api.

old way to use implement:

/** personInterface.js **/

const Interface = require('InterfaceJS');
module.exports = Interface.create('person', {
    nickname: 'string',
    age: 'number',
    greet: 'function',
});


/** index.js **/
const personInterface = require('./personInterface.js');

let melanie = personInterface.implement({
    nickname: 'mel',
    age: 28,
    greet() { return `Hi, I am ${this.nickname}`; }
}); 

melanie.greet(); // -> Hi, I am mel

The new way to use implement(). Have implement as a method on the interface api.

Example

/** catInterface.js **/

const Interface = require('InterfaceJS');
module.exports = Interface.create('cat', {
    fur: 'string',
    speak: 'function',
});

/** index.js **/
const Interface = require('interfaceJS');
const catInterface = require('./catInterface.js');

let kitty = Interface.implement(catInterface, {
    fur: 'taby',
    speak() { return `Meow meow meow, I am a ${this.fur} cat`; }
});

kitty.speak(); // -> Meow meow meow, I am a taby cat 

I am thinking of two possible syntaxes.

1. • take in one parameter that would be an array, that array would contain N > 1 number of Interface objects.
2. • take in N > 1 parameters of interface objects.

Both will compose all the passed in interface objects into one interface object. That new composed interface object will be returned.

The goal of this research is to find out how major open source libraries structure their app, what type of build process they use.

Question about other libs. Is everything shoved into one JS file. Do they use bundlers? Does it matter if the library is being used in the browser or in node?

One solution is to have the test folder mimic the src folder's structure. This would keep consistency between writing code for the lib and writing tests. ESLint follows a similar structure, need to research other open source projects to find other methods.

another solution would be to have the tests along side the modules to keep each module folder self contained.

add tools to bundle and minify the code for deployment. This process should create a 'dist' folder for future publication on npm

I tend to favor ESLint. Need to comb through the linting rules to see which I would like to apply. A possible alternative is to used a prebaked set of linting rules. (airBnB, google, netflix)