- Added a conversation timeline and a button in the upper righthand corner.
- Added a selection mechanism. It works, but I immediately see that selection is going to need to be more complex, that it should be handled as part of the view/control base classes.
- There are times, even in a project that isn’t a fun side-project, when building a quick, specific, simply solution is the best solution. Most of the time, this is the case. Building apps is not the same as building a library or and API. Only the end product counts. So long as the end product is great and maintainable, then the least general solution is probably going to be the easiest to test and the most bug-free.
- But there are other times when a part of your app will need to be used again and again. It’s like building a library/framework that’s specific for just your app. In these cases building a more general solution, even when you can’t immediately see all the possible use-cases, may be the best one.
- Having the experience to know when to build something general or when to cobble together a hack – that’s what separates the grownups from the kids. :-P
- App frameworks generally handle events in the view/controller hierarchy. It will take some extra work, but that’s what I need to do here.
- This is also the part of the app build where I begin to second guess myself: maybe I should have used React, or Angular, or heck… even jQuery! All of those things would have made quick work of the event handling, binding, etc. But at the end of the day, I’m much more content to build an app that has a minimum of dependencies. Although Electron apps tend to use more memory, I know that much of that comes from the monster dependencies like React. I still think staying away from those is the best way forward. So I build with as close to vanilla JS as is practical.
Day 11 gif is showing off the selection and the conversation view. Note that there’s a bug in the animation when sliding in the conversation view. There’s a race condition. The race is between the animating view and the DOM re-write that gets called after the network event returns the data from Micro.blog. If the network event returns quickly it nukes the animation. I need to find away to wait the update until after the animation.
What is this: these are random snippets from my dev journal working on a simple client app for fun. This is a non-serious side project, progresses very slowly, and will probably never see the light of day. The images may not perfectly correspond to the journal entry. In most cases I’ve added them later based on the relative time of git checkins.