-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
async data loading #63
Comments
Would these become a sync/await functions then?
…Sent from my mobile
On Oct 8, 2017, at 12:06 PM, Yoshua Wuyts ***@***.***> wrote:
Apologies for the rough draft here; I didn't have much time to phrase things here properly, but I hope the general idea makes sense. This is mostly so we can start thinking about this problem, and create a concrete starting point to work from.
Some of the more CMS-y applications make heavy use of server rendering, which produces pages that can then be stored on CDNs. In order for components to be rendered on the server, it might be useful if they could define an initial set of data before being rendered.
There's probably a good set of considerations as to the more finer grained details, but I was thinking an API like this might just be the right fit.
// button.js
var Nanocomponent = require('nanocomponent')
var html = require('bel')
function Button () {
if (!(this instanceof Button)) return new Button()
this.color = null
Nanocomponent.call(this)
}
Button.prototype = Object.create(Nanocomponent.prototype)
// This the new API.
Button.prototype.initialState = function (done) {
var self = this
xhr('/foo/bar', function (err, data) {
self.state.data = data
done()
})
}
Button.prototype.createElement = function (color) {
this.color = color
return html`
<button style="background-color: ${color}">
Click Me
</button>
`
}
// Implement conditional rendering
Button.prototype.update = function (newColor) {
return newColor !== this.color
}
In Node, we could wait for all these functions to resolve, before doing a final render. It's a lil messy, but might be the best we got.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Oh I see the callback now. |
Would this be a server only thing or would it execute in the client also? If so it'd be great if there was a way of rendering a intermediate loading state and not have the entire view have to wait to render due to some component having to fetch content. |
I'm not sure — I'd assume it would run in both; that way a dev can
rehydrate their app on the client, but if not doing SSR it'll still work :D
…On Fri, Oct 13, 2017, 07:57 Carl Törnqvist ***@***.***> wrote:
Would this be a server only thing or would it execute in the client also?
If so it'd be great if there was a way of rendering a intermediate loading
state and not have the entire view have to wait to render due to some
component having to fetch content.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#63 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACWlehXw0QljUKLueRhN72CVBrzrIX_8ks5sr1AngaJpZM4Px0CL>
.
|
How would an error case be handled? If an error is thrown or returned within |
yeah, it's what I was thinking |
Apologies for the rough draft here; I didn't have much time to phrase things here properly, but I hope the general idea makes sense. This is mostly so we can start thinking about this problem, and create a concrete starting point to work from.
Some of the more CMS-y applications make heavy use of server rendering, which produces pages that can then be stored on CDNs. In order for components to be rendered on the server, it might be useful if they could define an initial set of data before being rendered.
There's probably a good set of considerations as to the more finer grained details, but I was thinking an API like this might just be the right fit.
In Node, we could wait for all these functions to resolve, before doing a final render. It's a lil messy, but might be the best we got. Thanks & thoughts very welcome! 😁
The text was updated successfully, but these errors were encountered: