note_1
, note_2
, note_3
and he decides to delete notes 1 and 2, the first two key/value pairs can be removed without affecting the data in note_3
. In my current implementation, with a hash that looks like {3: Note object}, a new note would be added at index 4, even though 1 and 2 are unfilled. I don't think that this is too big of an issue, as it's not like that really puts an upper limit on the amount of notes a user could have.If I really didn't like the idea of the user getting up to notes with indexes in the hundreds or thousands after months of use and deletions, I could have the indexes be recalculated each time the app is run (so if the app loads a hash from localstorage with arbitrary keys
{10: ... 50: ... 51: ...}
, it would reposition the hash in memory so that the keys would be {1: ... 2: ... 3: ...}
.Since the hash is only ever read from localstorage once, when the app first opened, this would actually be pretty trivial to do, I would just have to add a bit more code here so that after the object was parsed, the keys were repositioned. I'm not sure if this is something worth doing for the presentation, though.
I'm still not satisfied with how my app objects are structured, but I don't have enough javascript experience to know what I can do to fix it. I can't even really describe what I'm unhappy about, other than the imbalance between the number of functions in each object, which I mentioned yesterday as well.
One specific thing I don't like is that in order for the notes to be persistent, they are loaded into the ui from the local storage here, in the
$.ready
event. However, this forced me to make the notes_hash object public, which would allow a user of this object to bypass my interface for manipulating the hash. I can do some jQuery to clone the object, but I don't know if there's a significant performance cost associated with that, and so far the security of the hash doesn't really matter so I just left it as is. At the same time, a performance cost wouldn't really matter, because the method is only being called once. I guess it's just a matter of personal preference.
No comments:
Post a Comment