Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 28 2018 04:17

    DylanPiercey on v7.0.4

    (compare)

  • Feb 28 2018 04:17

    DylanPiercey on master

    Improve typings. 7.0.4 (compare)

  • Feb 27 2018 07:44

    DylanPiercey on v7.0.3

    (compare)

  • Feb 27 2018 07:44

    DylanPiercey on master

    Add type definitions for tls op… 7.0.3 (compare)

  • Feb 27 2018 05:51

    DylanPiercey on platform-agnostic

    (compare)

  • Feb 27 2018 05:51

    DylanPiercey on file-size

    (compare)

  • Feb 27 2018 05:51

    DylanPiercey on add-code-of-conduct-1

    (compare)

  • Nov 20 2017 03:11

    DylanPiercey on v7.0.2

    (compare)

  • Nov 20 2017 03:11

    DylanPiercey on master

    Update size in readme 7.0.2 (compare)

  • Nov 19 2017 02:31

    DylanPiercey on v7.0.1

    (compare)

  • Nov 19 2017 02:31

    DylanPiercey on master

    * Update example links in readm… 7.0.1 (compare)

  • Nov 18 2017 04:31

    DylanPiercey on master

    * Update changelog. * Release 7… 7.0.0 (compare)

  • Nov 18 2017 04:31

    DylanPiercey on v7.0.0

    (compare)

  • Nov 18 2017 04:00

    DylanPiercey on v7.0.0-rc.12

    (compare)

  • Nov 18 2017 04:00

    DylanPiercey on master

    Remove default of 404 on status… 7.0.0-rc.12 (compare)

  • Nov 12 2017 18:53

    DylanPiercey on master

    * Organize types in namespace. … 7.0.0-rc.11 (compare)

  • Nov 12 2017 18:53

    DylanPiercey on v7.0.0-rc.11

    (compare)

  • Nov 11 2017 18:34

    DylanPiercey on master

    * Switch back to default export… 7.0.0-rc.10 (compare)

  • Nov 11 2017 18:34

    DylanPiercey on v7.0.0-rc.10

    (compare)

  • Oct 24 2017 00:00

    DylanPiercey on v7.0.0-rc.9

    (compare)

Dylan Piercey
@DylanPiercey
@maziey93 this is by design, similar to how when you submit a form without Rill it is reset. I have implemented an undocumented work around for this though, if you add a 'data-noreset' attribute to the form it should work. The reason this API is undocumented is because I have been trying to come up with a better API for this since I created Rill 😜
If you have any ideas let me know 🙂
Eyo O. E.
@maziey93
@DylanPiercey ooh cool... I will try it out, the thing was that when submitting a form i hadn't cater for visual feedback that a network activity was going on , plus with the fields cleared it made it super weird, like the app hung or something!! :worried:
Dylan Piercey
@DylanPiercey
Totally. What I typically do whenever a form is submitted is either show a toast popup or redirect the user to a new page to avoid this issue. It's trickier for things like searches though which is why I added this functionality. Another thing you could do is add a progress bar by using @rill/progress.
You will definitely want to let the user know in some what that things went through though :p.
Eyo O. E.
@maziey93
@DylanPiercey Hi, so i did try implementing my own type of visual cue with some sort of delegation but weirdly the click event i am listening for doesnt always get fired, any idea why that sort of thing would be happening
Dylan Piercey
@DylanPiercey
Hey @maziey93, want to post some example code? I should be able to help you out :)
What are you using for event delegation? And also what template engine are you using?
Eyo O. E.
@maziey93
@DylanPiercey vanilla js, with dustjs... nevermind though I seem to figured out why it was behaving erratic, sorry for bothering you
Dylan Piercey
@DylanPiercey
Glad to hear you figured it out! Never feel bad for bothering me :p. Always happy to help.
Also I have built a solid route based event delegation tool https://github.com/rill-js/delegate might be worth checking out. It automatically clears event handlers when you switch routes.
Eyo O. E.
@maziey93
@DylanPiercey nice, I will check it out... I like that your always reachable though 😁
Dylan Piercey
@DylanPiercey
I try to be :p. 👍
Constance Okoghenun
@okoghenun
Hi @DylanPiercey you may be wondering why myself @maziey93 & @imolorhe have been bugging you, we've been building beta.konga.com with rill on the client side. It's buggy but if you have some time please take a look and give feedback on things we could do better with Rill
Dylan Piercey
@DylanPiercey
@okoghenun I'd love to take a look. Is the project open source?
Constance Okoghenun
@okoghenun
@DylanPiercey No it isn't, but you can play round and inspect element :smile:
Dylan Piercey
@DylanPiercey
Seems to be working pretty well. Noticed a couple times that I needed to click the back button a couple times to actually go back (probably some redirect issue).
Gotta love everything working without js though, seems to be well implemented from what I can tell :).
If you guys had any feedback for Rill that would be awesome as well. Curious what struggles you guys had and what hacks were needed.
Constance Okoghenun
@okoghenun
We'd have to look into that issue you experienced with the back button it should ideally work since we are just using the window history objectwindow.history.back();.
It working without JS is the best part
Dylan Piercey
@DylanPiercey
😀👍
Constance Okoghenun
@okoghenun
I think the biggest feedback we have although it's not Rill bug, is compatibility with Express HTTP verbs. We already ran Express on the server and we just looking to port existing code, so we had to write bridges btwn Express and Rill which was fun :smile:
Dylan Piercey
@DylanPiercey
Gotcha. Curious to see what those bridges looked like. I believe you can mount Rill apps in express like so:
const eapp = express()
const rapp = rill()
rapp
    .use(...)
    .get(...)

express
    .use(...)
    .get(...)
    .use(rapp.handler())
    .listen(...)
Constance Okoghenun
@okoghenun
Didn't know we could do that, Plus express middlewares typically receive 3 parameters as against 2 for Rill, so we wrote a helper that will take Rills (ctx, next) => {...} and transform to (req, res, next) => {...} which our express middlewares were already expecting
Dylan Piercey
@DylanPiercey

Ah ic. Yeah Rill has a much closer API to koa but not exactly. The main reason I decided to make it different is because in most cases you shouldn't just take your existing middleware and use it in the browser since typically there are native dependencies and assumptions made in most server side middleware.

When I get home later today I'll double check the mounting of a rill app in Express, I know I've done it before but can't quite remember the syntax.

Constance Okoghenun
@okoghenun
That would be awesome! I'd be looking forward to it
Dylan Piercey
@DylanPiercey
Just tested it out and the method mentioned above seems to work fine for mounting Rill apps inside express apps :).
Might simplify things a little bit for you, however you'll still need the adapter for spreading the middleware arguments. It may be worth adding a utility like that to the rill org, curious what your thoughts are though?
Samuel
@imolorhe
@DylanPiercey that would be awesome, do people could work with that instead of needing to reinvent the wheel.
Dylan Piercey
@DylanPiercey
@imolorhe I agree, I'll probably try and get something out here soon.
Samuel
@imolorhe
@DylanPiercey we could probably even help out with that. You should put up the sample projects you created to test the rill and express combination too
Dylan Piercey
@DylanPiercey

@imolorhe FTR the goal is to use express middleware with Rill right?

Basically this:

import myExpressMiddleware from '..'

app.use(({ req, res }, next) => {
  return new Promise((resolve, reject) => {
    myExpressMiddleware(args)(res, res, err => {
      if (err) reject(err)
      else resolve(next())
    })
  })
})

Which could be simplified to:

import adapter from '@rill/express-adapter'
import myExpressMiddleware from '..'

app.use(adapter(myExpressMiddleware, args))

Or something like that?

Samuel
@imolorhe
@DylanPiercey Using express middlewares in rill, and also interfacing with the rill app in the same way you would interface with the express app.
For instance, mounting routers using app.use('/route', router), using router.all('/route', middleware), etc.
Dylan Piercey
@DylanPiercey

Regarding making the API the same as Express it's not something I'd consider right now. However both of the things you mentioned can be done like so:

app.at('/route/*', router) and app.at('/route', router) respectively.

Dylan Piercey
@DylanPiercey
Also @imolorhe do you mind posting what your current implementation is for converting express middleware?
Dylan Piercey
@DylanPiercey

Do you think it's worth supporting Express middleware setting headers that could be read by Rill middleware?

Here is my current implementation, which creates a full express request and response.

var express = require('express')
var setProto = require('setprototypeof')
var defaultApp = express()

module.exports = function fromExpress (middleware, app) {
  var config = { app: { configurable: true, enumerable: true, writable: true, value: app || defaultApp } }
  var newReqProto = Object.create(app.request, config)
  var newResProto = Object.create(app.response, config)

  return function (ctx, next) {
    return new Promise((resolve, reject) => {
      var req = ctx.req.original
      var res = ctx.res.original
      var oldReqProto = Object.getPrototypeOf(req)
      var oldResProto = Object.getPrototypeOf(res)

      // Add express prototypes.
      setProto(req, newReqProto)
      setProto(req, newResProto)

      // Execute express middleware.
      middleware(req, res, function (err) {
        if (err) reject(err)
        else if (res.headersSent) resolve()
        else {
          // Restore default http prototypes.
          setProto(req, oldReqProto)
          setProto(res, oldResProto)
          resolve(next())
        }
      })
    })
  }
}

I think it should solve most cases.

Patrick Steele-Idem
@patrick-steele-idem
@DylanPiercey I would worry about the performance overhead of changing the prototype for every request. I feel like that should be done at initialization.
Dylan Piercey
@DylanPiercey
@patrick-steele-idem are you suggesting mutating the native IncomingMessage and ServerResponse protos during init? Also AFAIK this is what express does internally on each request.
It wouldn't be ideal to when you have multiple express middleware being converted though.
Actually I think express does this per middleware as well https://github.com/expressjs/express/blob/master/lib/application.js#L230
Maybe this is why I consistently bench Rill to be much faster than express :p.
Oh actually that was just for mounted apps, but still.
Patrick Steele-Idem
@patrick-steele-idem
Express is an example of what you probably shouldn't do IMO. Monkey-patching has a cost. I'm curious, have you investigated https://github.com/fastify/fastify ?
Dylan Piercey
@DylanPiercey
Yeah I have taken a look a while ago and ran some benches against it but can't quite remember how Rill faired. I also looked at https://github.com/trekjs/trek and I remember that one being pretty close. I'll have to rebench fastify though it seems much more popular now.
Also re the express adapter, I'm not quite sure how else I'd implement this while maintaining support for all of express's apis. Koa would be easy to adapt since it has sensical constructor objects and doesn't patch protos.
Patrick Steele-Idem
@patrick-steele-idem
Yeah, there's probably not a better option if you need to fully support Express, unfortunately. It's too bad you can't monkey-patch the http.IncomingRequest object for a server in cases where you have to do it. The following might be nice:
const server = require('http').createServer();
server.IncomingRequest = class MyIncomingRequest extends http.IncomingRequest { ... };
Dylan Piercey
@DylanPiercey
Yeah that'd be pretty sweet. Although probably better for express to just switch to wrapping a request instead of augmenting existing :p.
Constance Okoghenun
@okoghenun
Hi @DylanPiercey Here is a gist to how we ensure Express routes play nice with Rill https://gist.github.com/okoghenun/cea9edce75e716a0301de697b8ec794a
All we need to do to get Express middleware methods to work for Rill is the do...