Atomic web development - Combining the power of npm, Browserify, Rework and more to build small, fully encapsulated client side modules
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
ust a little question regarding open pull request for adding "css watch support" and "autoprefixer" to atomify. Also the pull request that adds presentation slides and examples to atomify-example repository.
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.
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.
Otherwise, I'd be a happy person to see them accepted :-)
thx
I'd like to have something like a
Typed Web Component (if that makes sense)
If I think of a
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);
The
The visual grid rendered into the DOM is generated by the call to
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);
@serapath we have a “list” component that takes any type of “list-cell” you want to pass it
similar idea
Each list component takes an array of models and passes those models to the passed in constructor of a list-cell component
This is because we have "item list cells", "supplier list cells", "job site list cells", etc.
If people would use this in the wild, they could all start building interfaces with that kind of standardized approach and people could start mix and match components, because they only need to implement a certain interface :-)
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"
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"
@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
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)
it’s then up to the list to create each list cell with the data you pass to it
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?
why is the title and sidebar a part of this component?
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
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
I guess that API you should would be for a “page” or somesuch?
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?