For many, many reasons but the inclusion of JSX syntax in the tutorial is a super good reason to avoid it.
I still feel what I read about JQuery: strength of the tools aside, ease of learning a framework is what determines its long-term adoption.
Okay, I feel grumpy for writing this, I’ve made some cool React stuff in the past, but bleh, I do not want to fiddle with it again right now.
I really wasn’t able to get a good answer on the best approach to “run this JQuery on select views.” I could much more elegantly do this on every page, but that feels super sloppy: transforming the aria-label of a bunch of buttons that probably don’t even have popovers seems like it’s definitely going to screw someone up later. “Hey you added popovers to this page that say ‘new!’ on some eqiupment, now the aria-labels are all just ‘new'” “I did not know that would happen.”
This kind of gets us to the core of the problem: yes I currently know that there are no
aria-label attributes set anywhere on the site, and that popover text or popover-title text is always what should be label, but there’s no contract in place anywhere that says this should always be true. Two core problems:
- For someone editing the view later, this ‘turning the popover into a label’ isn’t terribly predictable behavior.
- If I were making this site from scratch, I would never engineer it to do this
I think the best approach may be “manual:” just declare the aria-label whenever a popover or popover-title is being declared.
The advantage of the manual approach is I could tailor some body text, label, and role for each menu button e.g. we could label each equipment button with the items name and include “text” with its stats and whether it’s currently equipped.
It kinda makes sense there’s no prescribed method to programmatically change the views that you just wrote.
So this is part of the drawback of my own experience: I have much much more experience working on giant crufty codebases than fresh ones. That I needed to know the history of why methods were named the way they were, why this was structured like this, all made sense when I was working on a 5-year-old codebase worth hundreds of millions of dollars.
But the whole purpose of something like Angular patterns is to create a site that makes sense even as it’s expanded as if it was created fresh today.
As it comes time to review 2015, I cannot help but remember my lowest moment.
No, not when I dragged myself, with a shattered knee and snapped wrist, out of a gutter. Not the ten minutes after that while I realized that no one would come running at 6 AM no matter how many times I called for help.
My lowest moment was when I begrudgingly opened an Angular JS tutorial so that I could make a new commit to [Habitica], logged in when prompted, and the codeschool interface seemed oddly greyed out. Finally I realized what it was trying to tell me:
“You have done every one of these lessons already. Even though nothing in the Habitica page templates looks even vaguely familiar, I assure you that early in 2014 you spent dozens of hours mastering almost every technique covered herein.”
The concept of knowledge decay, or knowledge atrophy, had never been put to me more clearly. I had even made a couple of Angular sites around February 2014, but trying to make even a small tweak over 22 months later felt impossible.
Onward and upward, I re-learned JQuery when I needed it, and it took way less time the second time. Hopefully I’ll keep tinkering with Habitica long enough that Angular will be entered into my mind’s permanent stores.