Currently it only takes an integer position or an object to compare against using indexOf. It's pretty rare in my experience with LML to ever actually know the position of a model in the list, but I almost always know the id of what I want. The current flow to get a revived model instance is:
var id = /* get id from DOM or somewhere */,
thing = lml.getById(id),
model = lml.revive(thing);
which is way less efficient than I'd like. I'd much prefer that it used the already-existing _idMap to look up the object & the internal _revive method could then be modified to just expect an incoming object directly instead of a position. The new flow would then be:
var id = /* get id from DOM */,
model = lml.revive(id);
with no need to iterate the list or have an intermediate object representation of the model. This is a bit tricky as currently LML uses _items & _models as arrays to represent object/Model values. Off the top of my head It seems like _models could be switched to an object keyed by id to work around those issues, but there may be unseen complexity/hassles in that choice.
tivac
commented
8 years ago
Currently it only takes an integer position or an object to compare against using indexOf. It's pretty rare in my experience with LML to ever actually know the position of a model in the list, but I almost always know the id of what I want. The current flow to get a revived model instance is:
which is way less efficient than I'd like. I'd much prefer that it used the already-existing
_idMapto look up the object & the internal_revivemethod could then be modified to just expect an incoming object directly instead of a position. The new flow would then be:with no need to iterate the list or have an intermediate object representation of the model. This is a bit tricky as currently LML uses
_items&_modelsas arrays to represent object/Model values. Off the top of my head It seems like_modelscould be switched to an object keyed byidto work around those issues, but there may be unseen complexity/hassles in that choice.