Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
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

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
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?)
Joey Baker
@joeybaker
hmmm… there is not
we do something like that
but we use atomify programatically
so it’s just a matter of sending it a different config based on process.env.NODE_ENV
Alexander Praetorius
@serapath
Atomify works through params on the command line and a config in package.json. Shouldnt the package.json support those kind of flags instead? But the atomify stuff in package.json slowly becomes quite big. Would it make sense to have a atomify.json file instead?
Joey Baker
@joeybaker
I’d vote for both options :)
we could look for an atomify.json file in addition :)
Alexander Praetorius
@serapath
Here is my current "standard atomify config":
  "atomify": {
    "server": {
      "open": true,
      "path": "index.html",
      "lr": {
        "verbose": true,
        "quiet": false,
        "port": 31337,
        "sync": true
      }
    },
    "js": {
      "entry": "SOURCE/index.js",
      "alias": "BUNDLE/bundle.js",
      "output": "BUNDLE/bundle.js",
      "debug": true,
      "watch": true,
      "transform": [
        "babelify"
      ],
      "standalone": "API"
    },
    "css": {
      "entry": "SOURCE/index.css",
      "alias": "BUNDLE/bundle.css",
      "output": "BUNDLE/bundle.css",
      "debug": true,
      "watch": true,
      "autoprefixer": {
        "browsers": [
          "> 1%",
          "IE 7"
        ],
        "cascade": false
      },
      "compress": false,
      "plugin": []
    },
    "assets": {
      "dest": "BUNDLE/assets/",
      "prefix": "/BUNDLE/assets/",
      "retainName": false
    }
  }
I forgot already what half of those options do and I already dislike that it consumes so much space in my package.json. I would really like to avoid yet another file, e.g. atomify.json in my repository, but I'm also afraid of making the package.json file even bigger.
What I would really like to see - but I'm not sure how that would affect atomify being used by dependencies of my module (e.g. recursive application of atomify to dependencies using their configuration) - is:
Alexander Praetorius
@serapath
I'll create my own cli tool, maybe called atomify-serapath or maybe just foobar and all it does is to require('atomify') and feed it my custom params and standard config files and standard dev, prod or test options. Of course, when creating atomify-serapath it's up to me whether I read that stuff from my package.json or create a seperate file or whatever... ...but that way I can hide all the config stuff that already became my personal standard or boilerplate inside of the cutom atomify-serapath module (and/or cli-tool)
It would be nice if an atomify-serapath module could use pure atomify modules as dependencies and atomify modules could use atomify-serapath modules as dependencies. I imagine the former part to be easy, but in order to make the latter part happen, it might require some conventions, so atomify knows what to do in case it encounters an atomify-serapath dependency :-)
Does that make sense to you?
Joey Baker
@joeybaker
It does. A separate module makes sense.
You’re kinda talking about the “shared configs” thing that eslint just did