3 ms·
> Taking a parent element for it to insert into would also be a poor API because it makes it harder to insert next to a sibling. To extend the documentation ex
by pc86 3y ago
> Taking a parent element for it to insert into would also be a poor API because it makes it harder to insert next to a sibling.
To extend the documentation example, wouldn't you just have "my-div-id-sibling" already and call
display("my-div-id", face);
display('my-div-id-sibling", someOtherFace);
Like almost all discussions that use language like "good API" or "bad API" this seems to me entirely personal preference. Personally I find anything where I end up having to call appendChild() myself a bad API.
- nox101 3y agoNo, that would not be better. Consider document.querySelectorAll('classIWantFacesIn').forEach(elem => { const face = generate(); elem.id = `face-${crypto.randomUUID()}`; // this line should not be needed display(elem.id, face); }); With the current API I'm required to make ids and make sure they don't collide with other elements. Vs document.querySelectorAll('classIWantFacesIn').forEach(elem => { const face = generate(); elem.appendChild(face.domElement); }); Now, no id is needed. It's objectively a better API to not need the id.
- streptomycin 3y ago(faces.js dev here) A nice thing about the current API is the face objects can be trivially serialized to JSON, which I need do in the application I originally wrote the library for. Also the `display` function works with a DOM element as the first argument too, in which case you don't need to make up an ID. That's how I use it. That being said, the API might not be perfect, but you should at least appreciate that it's been stable since v1 in 2015!
- nox101 3y agoSee other response this thread why passing in a DOM element is also not a good API. That said, I wouldn't have spoken up if someone hadn't claimed the API was good. Any one who makes a useful library that provides useful functionality people want is great! > it's been stable since v1 in 2015! That's awesome!