atomify/atomify

Atomic web development - Combining the power of npm, Browserify, Rework and more to build small, fully encapsulated client side modules

Joey Baker

@joeybaker

@serapath we’ve adopted the pattern that each “list-cell” is responsible for re-rendering itself if it’s model changes

that takes care of the “data-binding” problems for us

Alexander Praetorius

@serapath

@/all thx and hello :-)

Otherwise, I'm still wondering if you have some kind of "interface pattern" that you use for the "list cell" component you inject into the "list" component. I immediately think of machinepacks(but maybe there are alternative and better specs)

Joey Baker

@joeybaker

Our approach is for the parent list to take two options. listCell (which is a constructor) and listCellOptions

it’s then up to the list to create each list cell with the data you pass to it

Alexander Praetorius

@serapath

var componentAPI = componentName({
  container      : `domNodeOrSelector`, // maybe it should always be a dom node 
  options        : {/* configuration options */},
  data           : `modelOrStreamOrEventEmitter`, // to initialize or update stuff
  children       : [ // this is optional, because maybe the component can use defaults if not provided
    { '__title'  : titleComponent   },
    { '__list'   : listComponent    },
    { '__sidebar : sidebarComponent }
  ]
});

This does say nothing about the Interface that is returned from a call to any component, like componentName(..), titleComponent(..), listComponent(..) or sidebarComponent(..).
But I imagine, that it should be possible to somehow formally define an Interface, so that I can easily write a component that I can inject into an existing component to change it.

Maybe node machines are nice for defining those interfaces, but maybe there are alternatives :-)
What do you guys think of that?

Joey Baker

@joeybaker

possible, but I’m inclined to think that it’s to complex to have that many children?

why is the title and sidebar a part of this component?

Alexander Praetorius

@serapath

Current "components" are primitive, e.g. "div"s, "input"s, "button"s, "span"s, ... but more complex components can and should be build.
My whole website is a component. Maybe not a really "re-usable" one, but there are best practices for certain kinds of websites and i could swap out menuComponent or articleComponent if i need too, or just build a new website component (by forking the existing one and changing it completely... The goal is to start with simple components and slowly build more complex ones over time

There is no end to how complex components can get and if you have solid "complex building blocks", you can create new even more "complex components" quite fast :-) But that only works if its easy to combine them and switch out some of them, so i thought having a way of defining some "contracts" how they work, thus "Interfaces" that need to be fulfilled, would be nice.

Basically: components that turtle all the way down, there is nothing else, just components everywhere

Joey Baker

@joeybaker

totally agreed there!

I guess that API you should would be for a “page” or somesuch?

Alexander Praetorius

@serapath

Are you aware of any project that is trying that approach already? Because I would rather contribute then re-inventing the wheel

Joey Baker

@joeybaker

not really?

I mean… we at Getable sorta do that by convention already :)

but… might be a good idea :)

it would really give people a way to see how atomify is just components all the way down

I guess ember’s router and react-router sorta kinda already propose a similar idea

you might look at those?

Alexander Praetorius

@serapath

I know, but everyone does it slightly different and maybe conventions could be "baked into" a cli tooling that helps with scaffolding (if neccessary at all) or at least specifies the standards and tests if written code is compliant

Joey Baker

@joeybaker

yea, I see what you mean

I don’t know of anything that exists for that :(

Alexander Praetorius

@serapath

my eyes often start to bleed when i look at ember or react, even though i like many ideas they have

Joey Baker

@joeybaker

heh…

yea I know the feeling

we’re starting to adopt it at Getable

once you get past the jsx

Alexander Praetorius

@serapath

ember or react or both?

Joey Baker

@joeybaker

it’s actually really, really nice

just react

Alexander Praetorius

@serapath

dammit :-) i would like to use hyperscript instead of jsx

Joey Baker

@joeybaker

and while I initally hated the idea of “templates in js"

I got used to it

Alexander Praetorius

@serapath

there is also "virtual-hyperscript" and there is "react-hyperscript"

Joey Baker

@joeybaker

it’s actually convenient

I’m not fimilar with those?

Alexander Praetorius

@serapath

i have to go fast - i have an appointment. check out "dominic tarr" and "raynos" they do hyperscript and virtual-hyperscript

otherwise i'll post the links later. "react-hyperscript" you can find on npm

Joey Baker

@joeybaker

Alexander Praetorius

@serapath

There is a standalone virtual dom library from matt esch.
Hyperscript is a pretty interesting library and a "virtual dom" version exists:

There are also some modules to use stream for updating the dom that i like a lot

hyperspace which uses hyperglue which uses hyperstream :-)
and i found a streaming http server hyperquest

You said earlier:

@joeybaker
possible, but I’m inclined to think that it’s to complex to have that many children?
why is the title and sidebar a part of this component?
and when i described stuff in more detail
@joeybaker
totally agreed there!
I guess that API you should would be for a “page” or some such?

I would actually like to brainstorm about a component interface that enables everything in a page to be a component.
The most "top level" components could be different kinds of "webpageComponents" (which set meta-tags, html, head, body, css-reset and a lot of other things) so people could have something like:

index.html

<body><script="bundle.js"></script></body>

bundle.js

var webpage = require('webpage'); // encapsulates best practice boilerplate for certain kinds of projects
var webpageAPI = webpage({
container: document.body,
options: {/* some configuration depending on the project that should be built*/},
data: {/* some webpage specific data or e.g. RESTful endpoints to fetch the data */},
children: { /* inject some components to be used to render page in detail - if not provided might fallback to default components */}
});
/* Below the "webpageAPI" might be used to interact with the page or register some listeners to react on certain things */

Challenges

I'm thinking of using leveldb (a version that wraps indexdb) to cache everything on the client side and potentially replicate with a remote leveldbif provided in options. A nice thing is, that leveldb has a library sublevel to provide a leveldb interface to a subset of data in the database. This could be "passed down" into certain components in the DOM tree. Furthermore, I'm thinking of using BEM conventions in css and templates for all components and to mark "insertion points" for injected components from the "children: {..}" parameter.

what kind of elements or aspects need to be covered by the hopefully standardized componentAPI?
....

I'm not sure if the atomify chat is the right place to discuss these things, but I really enjoy the feedback from you and whether you imagine this kind of approach would be of any value or not (perhaps because there is already plenty of stuff out there that covers what i'm trying to achieve)

Joey Baker

@joeybaker

I’m happy to have the discussion here :)

unless you wanted to start a repo/org to host this idea :)

I’m curious about what you’re proposing. From what I understand, there’s a good idea here. Basically: you want someway to formalize sending page structure and data to a browser. This is something more formal than html because it tries to automate much of the boilerplate (everyone wants a header/footer, let’s just automate that) and muxing data into the presentation.

I mean… that is the challenge of all frontend programming :)

Alexander Praetorius

@serapath

I was just thinking of an atomify init option as an alternative to npm init, that generates a "package.json" file with default values for the atomify configuration. I'm currently tryin to found a coding school for kids and might teach them atomify. I'm basically copy&pasting always the same atomify configuration from one project to the next - a init option would be neat.

Joey Baker

@joeybaker

sounds amazing

you might also like https://github.com/joeybaker/generator-iojs

Alexander Praetorius

@serapath

looks nice. lots of stuff in there, so it'll take a while.
But while we are at it ;-) Is there an option to tell atomify to start in dev, production, test mode so that i can supply different configuration to it? (If not, what would be a neat way to approach that?)

Where communities thrive

People

Repo info

Activity

Challenges