Skip to content
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

Components #606

Closed
wants to merge 12 commits into from
Closed

Components #606

wants to merge 12 commits into from

Conversation

yoshuawuyts
Copy link
Member

Adds https://github.com/yoshuawuyts/choo-component-preview/ to Choo. Semver minor. Updated the example too; seems to be a bit faster / easier to reason about (yay!)

@yoshuawuyts
Copy link
Member Author

Oh, also note that this does not contain the PRs proposed in https://github.com/yoshuawuyts/choo-component-preview/pulls yet — we should merge those in before then.

Copy link
Member

@tornqvist tornqvist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking really good! I left some comments. I also had some trouble with the example, choo-devtools was throwing errors left and right.

// state
var _state = {
events: this._events,
components: {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed in the examples that this is being used for a kind of shared local state. Seeing as it doesn't tie in to the framework in any manner, it's easy enough to set up yourself and that choo in general is very unopinionated as to how one chooses structure state. Is there really a need for a default component property?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right that there's not really a need for it, but it makes it just a little bit nicer if you choose to use it. Using a single state has lots of benefits: tracing, debugging, logging — it all becomes a lot easier.

Also, by naming it a particular thing, all applications now become a little more portable between each other. If you're writing multiple apps and sharing local state as global, it'll always be on the .components property of state.

I'm feeling this is kind of similar to window.initialState for server rendering — not essential, but having it in there clears up a line of decision making, which creates a more cohesive experience (:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm totally on board with the one state-pattern, and now that you put it that way I guess it does make sense to have a default component property on there. I guess it's just a matter of properly documenting it as a recommended way of doing things.

index.js Outdated
var res = handler(self.state, function (eventName, data) {
self.emitter.emit(eventName, data)
})
var res = handler(state, emit, cache)
Copy link
Member

@tornqvist tornqvist Dec 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had this crazy idea while working with the preview. By adding just one line here, we can support top level components, as in component as view. If the talk of having async components (like the static getInitialProps in Next.js) were to be realized, and also with the trouble some newcomers have with figuring out async views, I figured it might be worth considering?

But really, this is more of a "why not?" than a proper suggestion. Just wanted to get it out there.

if (typeof handler.identity === 'function') res = cache(handler, state, emit, cache)

Copy link
Member Author

@yoshuawuyts yoshuawuyts Dec 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely sure what this code does. I'll have to take a look at the other PR I guess haha. I trust you it works — and fully subscribe to the benefits you're laying out here.

Also been thinking about Next.js style SSR rendering, and think once this patch lands we can work out the details to get some combination of events / class methods in there to make it streamlined. But this is probably first C:

edit: this is to say: feel free to push this change! — It'd be swell to have this working at the top level!

Copy link
Member

@tornqvist tornqvist Dec 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, I could have been more clear and have supplied a proper example. I added it in there now but didn't wanna update the todo example seeing as the main view wouldn't benefit from it in any way. But for the sake of documentation, this is what it would look like:

module.exports = class MainView extends Component {
  static identity () {
    return 'main-view'
  }

  update () {
    return true
  }

  createElement (state, emit, render) {
    return html`
      <body>
        <section class="todoapp">
          ${render(Header)}
          ${render(Todos)}
          ${render(Footer)}
        </section>
        ${render(Info)}
      </body>
    `
  }
}

@tornqvist
Copy link
Member

About the GC, I implemented what we had in the preview over in my fork (tornqvist@783c5b1), should I push that here?

@yoshuawuyts
Copy link
Member Author

@tornqvist yeah, please do push! :D

@tornqvist
Copy link
Member

tornqvist commented Jan 3, 2018

Just a heads up, @yoshuawuyts. If this is to be the path forwards with components, we've got an issue with SSR. I was just implementing a version of this PR and realized that since this.state is replaced in Choo.toString, all instances of the cache are outdated after first render, as they reference the state from initialization.

edit: I solved it using a Proxy (only in Node). Idk if it's a feasible solution for choo but it got the job done…

@yoshuawuyts
Copy link
Member Author

Replaced by #639

@yoshuawuyts yoshuawuyts closed this Mar 7, 2018
@yoshuawuyts yoshuawuyts deleted the components branch March 7, 2018 13:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants