4 ms·
So how do you propose storing a JSON object with .attr()? Do you JSON.stringify(), store as string, get as string, JSON.parse()? Seems like a no-brainer to abs
by taitems 14y ago
So how do you propose storing a JSON object with .attr()? Do you JSON.stringify(), store as string, get as string, JSON.parse()?
Seems like a no-brainer to abstract it away into a helper function, but then you're just duplicating .data() functionality, surely?
- latchkey 14y agoI haven't had that usecase. I just store 'keys' in the attributes and do lookups in objects (which have been created from JSON) to get the 'values'. For example, if I'm displaying a bunch of objects as rows in a table, I do something like this: tr.attr('data-key', key) as I'm looping over my objects. Then, if there is say an 'Edit' button as a column in that row, all I need to do is button.on 'click', (e) -> $(e.currentTarget).parents('tr').attr('data-key') to figure out which row was clicked on.
- taitems 14y agoInteresting concept, but seems like the same underlying principles of the .data() method (or at least how it was originally planned) except for the direct DOM manipulation. eg: A central object store where references are bound to DOM objects and not explicitly set on the object itself. Therefore no type coercion/guessing. Regardless, if they "fix" the .data() method to your liking, at least then you'll be writing compatible, future-proof code. I've never had the problem myself so can't really weigh in, but replicating core functions has never ended well in my experience.