add: ctx.locals as a recommended namespace for passing information to the frontend

[matthewmueller]

Just throwing this PR out there. It was discussed in: #338.

Basically this gives you a namespace to attach to that you don't have to worry about this object being undefined. Alternatively, you could always add:

app.use(function *(next) {
  this.locals = this.locals || {};
  yield next;
});

at the top of your stack. I feel like this is common enough use-case that it should be added to core, but open to your thoughts.

[matthewmueller]

alternatively, we could call it ctx.state to avoid the confusion of express locals

[tj]

sweet! I agree with the name change to differentiate, ctx.state sounds fine to me! A little section in the docs would be awesome too if you have a minute

[matthewmueller]

done! let me know if there's anything else I should update.

[jonathanong]

can we squash this? :)

[fengmk2]

confusion of ctx.status and ctx.state, read-write similar.
I think ctx.state is not a good name.

[jonathanong]

maybe if english is your second language :) it's not like you pronounce it state-us. both are okay with me.

[hallas]

When we add this we need to heavily stress the idiomatic use of this object to store auxiliary information.
Since we now provide an official way of doing this, we need to make sure people get it.

[fengmk2]

@jonathanong 😢

[matthewmueller]

can we squash this? :

@jonathanong sure, not too familiar with that workflow. Should I open up a new PR with the single commit?

[dead-horse]

@matthewmueller git rebase master -i

[matthewmueller]

@dead-horse right, but i can't push this on the same branch because the commit histories don't match up.

[hallas]

git push --force 👯

[matthewmueller]

ya'll are living on the edge, huh... pushed!

[tj]

thanks man!

[fundon]

wow, I missed something.
good news.

thanks @coderhaoxin
yes, we can deprecate it when release new version.