scramjs / express-web-components Goto Github PK

Instead of mutating the child nodes and using a property observer to call init, why don't you call a method on the child nodes? You can then pass in all of the properties of the express bundle as parameters. This will be more functional, less mutations.

Story: Developer can set the port directly in the HTML to any available port.

Acceptance tests:

• Set the port to multiple values, and each time check that you can make a request

This repository was originally published on NPM, but I'm realizing that it is too difficult to try to work with Polymer in NPM until Polymer officially makes the switch. You can follow the issues below, and once Polymer officially supports NPM, we can make the switch:

• Polymer/polymer#2578
• Polymer/polymer#326 (comment)

Make sure the types are accurate, especially the callbacks. There are parameters that Express and Node.js might pass back that I might be missing

I don't think we have the functionality for router.all: http://expressjs.com/en/4x/api.html#router.all

The use case I'm having trouble with is setting up socket.io. I do not have access to the server before it starts listening, and so I can't hook up socket.io correctly. What if we could pass in a function to be applied with the server before the serve starts listening in express-app?

Think of the best way to add code examples.

Polymer 2 should allow class member methods to be data-bound to local element properties. This will be syntactically better than setting the handlers on the component class' context, like we are doing it now. Make the switch once Polymer 2 is stable.

Story: Bind a function to 's callback property and the function runs after the app is initialized

Acceptance tests:

• Bind a function to express-app's callback property and ensure that the function runs after the app is initialized

Story: The developer can set the port in JavaScript through data binding.

Acceptance tests:

• The port is set multiple times through data binding, and requests are made to ensure it works.

Story: The hostname is set directly as a string value of an HTML attribute

Acceptance tests:

• Set the hostname through the HTML attribute on express-app and ensure that the express app is listening at that hostname
• Set the hostname through data binding and ensure that hte express app is listening at that hostname
• Do the above test for multiple hostnames

Once Polymer 2 is stable, make the switch.

Make sure the components can handle the idea of a sub-app as described here: http://expressjs.com/en/4x/api.html#app.use

Story: initializes children

Acceptance tests:

• Put children inside of an express-app and ensure that they are initialized and hooked up to the express-app correctly

This is how the express api works. Perhaps throw an error if they try to do this

Having a behavior is tying us to Polymer, and it is potentially more cumbersome to the user than necessary. Figure out how to get rid of it. I think we should be able to pass/set the init function to the child nodes from the parent node.

If someone adds a child element at runtime, make sure the parent element responds appropriately. I'm not sure we can dynamically add middleware, because we might have to restart the server...But maybe

I put the scripts for each component in the example in a separate file to prepare them for all es-next and TypeScript features, but I really like having the components inline. Once this issue is figured out, switch to inline scripts again.

Story: User Story - No callback is set on , and so the default callback runs

Acceptance tests:

• Initialize express-app without a callback and ensure that the default is called

It turns out that routers can take methods too: http://expressjs.com/en/4x/api.html#router.METHOD

I think I can get rid of the setTimeout hack in express-app if I use default values and a multiple property observer.

These components are stand-alone and relatively simple. Think about writing them vanilla. We could then drop the extra complexity that is Polymer. It would be nice to not have to load Polymer at all, and with Electron we can just depend directly on the web component specs available to us. Applications built with these components can and I believe should be written in something like Polymer, but vanilla is sounding pretty good for these and other Scram.js universal web components.

What happens if you have a parameter that can be a string or an array of strings? Make sure all parameter types are handled correctly.

I'm not sure the implications of peer dependencies, but it might be appropriate

This potentially opens the door to allowing users to use class-member methods to describe the middleware callbacks. I'm thinking we can allow the user to do whichever one they want...bind to the callback property, or listen to the callback event.

It seems like this should be handled declaratively somehow: http://expressjs.com/en/4x/api.html#router.param

And the same thing needs to be handled at the app level: http://expressjs.com/en/4x/api.html#app.param