This basically allows you to use express style code for your middleware
Right, it's a cool idea but I think at that point it would be best to wrap @rill/http instead of Rill. It wouldn't be too hard to fork express and use @rill/http in place of http to achieve a similar result with less overhead and more compatibility.
The reason I haven't done something like this is that I believe using express middleware in the browser can be dangerous because you don't necessarily know if the code is optimized for the browser or server, or if it will even work. With any middleware in the rill-org you are guaranteed that the middleware will work appropriately in both environments.
At every point in the design of Rill's api's and middleware I have been conscious of both browser side ergonomics and server side, while ensuring optimal code is delivered to each environment.
@DylanPiercey I agree that using just any express middleware on the browser may not be the best idea but I'm of the opinion that the decision should be left to the developer. For our use case we had already invested a lot in our express codebase and wanted a to reuse the bulk of the components we had written for the server but that would work well on the client
That's fair enough and I'm glad to hear that solution made things easier for you. This is exactly why Rill has the
#setup method, where you can do stuff like app.setup(expressAdapter) which is essentially your transformer. I just wouldn't add something like that to the org because I can see it being far to easy for developers (whom in my experience seem to already have a hard time distinguishing client and server with this approach) to shoot themselves in the foot.
Always feel free to reach out if you have any issues 😄
Hi @DylanPiercey , is this the only way to trigger a page reload routed through rill rather than the server?
https://github.com/DylanPiercey/submit-form/blob/master/client/index.js#L30
https://github.com/DylanPiercey/submit-form/blob/master/client/index.js#L30
If you just want a reload you can do
ctx.go(ctx.req.href)
See the example from the readme:
// Here we listen for `keyup` events that match a `.verification-code` element.
delegate.on('keyup', '.verification-code', (ev, go) => {
// `currentTarget` will be the element that matched the selector.
const input = ev.currentTarget;
const code = input.value
// The second argument is the 'go' utility, which is much like native fetch but tells Rill to navigate.
if (code.length === 5) {
// In this case when we have 5 characters, we navigate to the submission page.
go('/submit', {
method: 'POST',
body: { code }
})
}
})
Also I was wrong, it's not 'ctx.go' it is passed in to event handlers.
One other thing to note though is that with @rill/delegate you need to bind the event handler for each request because all event handlers get reset (so that if you navigate to a new page it doesn't take all the old handlers). Let me know if that doesn't make sense.
Just curious, what module bundler are you using? Webpack/Browserify/Rollup/Lasso?
Or @rill/html?
Sorry, just trying to get an idea of how people are using Rill :).
Didn't know dust did client side rendering.
What are you doing when this happens?
Thanks, it looks like it can't find
ctx.req.original.socket.server within this:function delegate (options) {
return function delegateMiddleware (ctx, next) {
// Store reference to server for later.
_server = ctx.req.original.socket.server
// Clear all listeners.
for (var type in _listeners) _listeners[type] = []
// Continue request.
return next()
}
}
Because that should work as far as I can tell atm