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
Thanks for all the work @serapath! Atomify 6.1 has all your changes.
Alexander Praetorius
@serapath
wow :-) cool
thx
Joey Baker
@joeybaker
thank you!
Alexander Praetorius
@serapath
I have a general questions about a specific approach to components and whether its stupid or not and if something like that exists already or not.
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 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);
Alexander Praetorius
@serapath
Does something like that exist? Or maybe its a stupid idea...
Joey Baker
@joeybaker
we’ve sorta built something similar at Getable
@serapath we have a “list” component that takes any type of “list-cell” you want to pass it
similar idea
Daniel Erickson
@Techwraith
Yep, we definitely do that at Getable. We have a list component, a "randomized" list component, and a searchable list component. Likely we'll have sortable and filterable soon too.
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.
Alexander Praetorius
@serapath
so i guess a "list cell" needs to implement a certain interface which is what i meant by "typed component"
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"
Joey Baker
@joeybaker
@/all @serapath is now a maintainer of Atomify. Welcome!
@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?