Atomic web development - Combining the power of npm, Browserify, Rework and more to build small, fully encapsulated client side modules
i successfully added autoprefixer support. The part of code i touch is the same that's touched by the open pull request, so i dont know whether to base of the "autoprefixer branch" off of that or just of master, but then i have to rebase it again, once the "css watch" PR lands.
In addition to that, i was adding a readme comment in "atomify-css" to reflect the new autoprefixer option, but i have to say, i dont like the way the readme is currently structured at all. I think the best way would be to put in a "code snippet" of a package.json file with ALL POSSIBLE "Atomify Options" enabled and with comments around it, that describe their logic + give links where to find additional information if necessary (e.g. list of rework plugins, list of browserify transforms, link to autoprefixer page and all possible options for that, and so on ....).
In addition to that, it should include "sensible best practices" so that people can just copy&paste the presented config to their package.json and not worry much about it.
hi guys,
following scenario:
my-component module:
package.json:
{style: main.less}main.less:
import 'my-mixins' //works well
import 'another-component' //works well
import 'path/to/a/3rd-party/css/file.css'app-module:
main.less:
import 'my-components'atomify-config:
css: {
entry: 'src/main.less',
alias: 'src/app.css',
transforms: ['partialify'],
assets: {
prefix: '/temp/fonts/',
dest: 'temp/fonts'
}
}...what happens here is that the 'file.css' import is not bundled/reworked into my output.css...
So, in general I would like to use atomify with the builtin npm-less but I have also to be able to import/bundle css-files like done with rework-npm.
Any ideas?
cheers, jan
I got some feedback and tried to do changes to make the PR's comply with those requests. If there are more "issues" that hold back the PR's from being accepted, I'm happy to change stuff more.
Typed Web Component (if that makes sense)
calendar, a pinterest wall and a todo list, they could all be visual grids in the DOM, that support pagination, filtering, searching, sorting and dozens of other features. But a todo item looks different from a pinterest card looks different from a calendar day. So I came up with example code i'd like to write...
var container=document.body, arr=require('data.json'), grid=require('typegrid'), elem=require('arrElem'); var API=grid(container, arr, elem);grid knows it's css/htmljs and so does the elem.The visual grid rendered into the DOM is generated by the call to
grid(...), where one elem(...) per item in the array is added.
var calendarAPI = grid(container, array, dayComponent), pinterestAPI = grid(container, array, pictureComponent), todoAPI = grid(container, array, todoComponent);
I imagine, the "data" passed in, should not be simple arrays, but something like "event emitters" or "streams" or anything that can update during "runtime", so that you can do more than just an initialization of data, but have some kind of "data binding"
machinepacks(but maybe there are alternative and better specs)
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?
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