tbranyen/diffhtml

Better naming structure for sub-packages

tbranyen opened this issue · 4 comments

tbranyen commented

It's hard to determine from looking at the packages what they are. For instance what is diffhtml-logger and what is diffhtml-components?

What about the following naming scheme:

  • Middleware
    • /packages/diffhtml-middleware-logger
    • /packages/diffhtml-middleware-verify-state
  • Components /packages/diffhtml-stateful-components
  • Babel /packages/babel-plugin-transform-diffhtml
mAAdhaTTah commented

What is "diffhtml-stateful-components"? Are there other packages that would be "components"?

tbranyen commented

@mAAdhaTTah The package name can't be a complete definition 😛, but I think adding stateful helps separate it from other kinds of components like stateless. The actual package exposes:

  • Component
  • WebComponent
  • PropTypes

I'm still debating if it should also re-export diffhtml properties to make imports more succinct. Like:

import { html, Component } from 'diffhtml-stateful-components';

class MyComponent extends Component {
  render() {
    return html`Test`;
  }
}

Not sure what to name it really. It's an "extra" or "optional" package, maybe: diffhtml-extra-components?

mAAdhaTTah commented

lol I just thought

Components /packages/diffhtml-stateful-components

suggested there would be other packages in the category "Components".

FWIW, Inferno has its ES6 class-based components in a separate package they just call inferno-component, so it's not that odd.

tbranyen commented

Sounds good to me, I've renamed the middleware (will also help with consistent versioning since I've already published 1.0s for some of the existing middleware).