doriansmiley / lotusjs-mwv Goto Github PK

The new method signature would be:

public mapObject(key:any, constructor:Function, useSingleton:boolean=false, params:Array<any>):void{

We then could refactor inject pass the params in the call to the constructor function as follows:

return new (map.constructor as FunctionConstructor).apply(this, params);

I'm not sure if this will mess with scoping as this would refer to the context. I think a better approach would be something like

return new Function.prototype.bind.apply(map.constructor, params);

The code examples need to be updated with the latest code from the sample app in order to ensure they should extension from LotusMVW objects

I found this testing framework referenced on https://vuejs.org/v2/guide/comparison.html.js. It looks relatively easy to create a version for LotusJS and issue a pull request. Also, be sure to create a separate ticket in lotus-mvw for this.

https://github.com/krausest/js-framework-benchmark

Video:
Stack overview https://www.youtube.com/watch?v=ykp6Za9rM58
Client: https://www.youtube.com/watch?v=eHjP2WFt0zU

Blog:
https://dev-blog.apollodata.com/apollo-client-2-0-5c8d0affcec7

GraphCool Framework, this tool works with Apollo Server
https://github.com/graphcool/framework

Apollo Client:
https://www.apollographql.com/client
https://github.com/apollographql/apollo-client

Apollo Engine:
https://www.apollographql.com/engine/
https://www.npmjs.com/package/apollo-engine

Apollo Server:
https://www.apollographql.com/docs/apollo-server/

Schema Stitching is amazing! Learn about it. Basically you can modularize a schema so it can be served from a disperate server. This is a critical thing for SaaS components which will want to combine resources from all over the web. Using mediators to speak GraphQL with Schema Stitching will allow web components to interact with data form all over the internet in a nice loosely coupled way. Ir also ensures data models are portable between applications, something which is sorely needed and will lead to less adapters being used by web components themselves. It's even possible that the entire adapter patterns for mediators could disappear as GraphQL schemas become the native data models for components.

GraphQL is a huge freaking deal. With schema stitching you can actually standardize data models across the web. Independent data sources can define their data for consumption in third part applications in a universal format. This is ground breaking. When combined with web components you can model, consume, and visualize every piece of data in a plug and play manner that is independent of implementation details. This will change everything.

Allow the central event bus to define interceptor functions. The idea would be that these functions will be called before the event call back functions are executed. Consider the following interfaces signature taken from parsley:

MessageInterceptor:
http://www.spicefactory.org/parsley/docs/2.1/api/parsley-spicelib-flex/org/spicefactory/parsley/core/messaging/receiver/MessageInterceptor.html#propertySummary

MessageProcessor:
http://www.spicefactory.org/parsley/docs/2.1/api/parsley-spicelib-flex/org/spicefactory/parsley/core/messaging/MessageProcessor.html

The MessageProcessor exposes a proceed method. I think the central event bus should check if interceptors are defined and if so it should create a new instance of a concrete MessageProcessor instance assigning all the callback functions as separate MessageInterceptor instances. The MessageProcessor would then iterate over all the MessageInterceptor instances calling the intercept method of each passing itself. The MessageProcessor's proceed method will then pop the processed MessageInterceptor from the collection and wither call the next MessageInterceptor in the collection or finish execution and call the MessageProcessor's destory method. IMPORTANT: execution of a MessageInterceptor must occur in a try catch block. Also, MessageProcessor's should also expose a cancel method which can also be called by the MessageInterceptor. This will trigger the MessageProcessor's destroy method and clean up.

Update the readme docs to include samples of mapping objects with constructor parameters, and a sample of passing a key value in @inject which will be used in place of the objects type. Also include information of the fact that targets of @injectable must expose an IContext property and pass in constructor. Include example of how to pass a context ref in the injector, for example:

 this.injector.mapObject(TestObjectSub, TestObjectSub, false, [this]);

Note which base classes already expose a Contextproperty and pass in the constructor.

Concrete mediators must be application specific. Create mediators as part of #3 .

Consider using yoemans: http://yeoman.io/

#Refer to the following article for building a CLI in NodeJS:
https://developer.atlassian.com/blog/2015/11/scripting-with-node/
https://www.sitepoint.com/javascript-command-line-interface-cli-node-js/

An archive with the required template files is here: https://www.dropbox.com/s/dkld3z00fy1hpb0/lotusEmptyProjectFiles.zip?dl=0

The tool should take in a project name and a namespace. Once executed the tool will:

• Add webpack.config.js setting

entry: {
        'myNamespace-UMD': './src/index.ts',
        'myNamespace-UMD.min': './src/index.ts'
    }
....
output: {
        ....
        library: 'myNamespace',
       ....
    }
externals: {
        "lavenderjs/lib": "Lavender",
        "lotusjs-components/lib": "Lotus"
    }

where myNamespace was is the one supplied by the user.

• Add tsconfig.json
• Add package.json
• Add .gitignore
• Add .npmignore
• Create globals/Globals.js setting up namespace with the one provided by the user
• Create empty js directory
• Create empty css directory
• Create empty index.html file
• Create empty lib directory
• Create scripts directory with the following files: commands.txt, testSauce.sh, typescript.sh. Commands.txt will be writtes as follows:

#test on sauce labs
export HOME=PATH

cd $HOME
sh ./scripts/testSauce.sh

#test local
export HOME=PATH

cd $HOME
npm test

#compile typescript and webpack
export HOME=PATH
cd $HOME
npm run build

Where HOME is the path to the current working directory

• Create a src directory with the following files: context/Context.ts and index.ts. Context.ts will be written as follows:

import * as Lavender from 'lavenderjs/lib';
import * as Lotus from 'lotusjs-components/lib';

export class Context extends Lotus.Context{
    
}

index.ts will be written as follows:

export * from './context/Context';

• Create a test directory with the following files: config/typescript-test-karma.conf.js, config/karma.conf-ci.js, and an empty unit directory. Both files need the following path adjusted:

'../lib/myNamespace-UMD.min.js',

Where myNamespace is the namepace supplied by the user.

• run npm install with --save-dev passed if the dev flag was entered by the user

This should be a typescript application. Could recreate image gallery app in typescript.