7 ms·
I see the point but noone in their right mind would write the javascript like that. When written better it's a good amount shorter than the React solution. htt
by orheep 11y ago
I see the point but noone in their right mind would write the javascript like that. When written better it's a good amount shorter than the React solution.
http://pastebin.com/wbGZZs7U http://pastebin.com/wbGZZs7U
- chibicode 11y agoI totally agree, in fact I'm going to link this :) The point I wanted to make is that every feature requires a bit of refactoring like this, whereas React puts some structure.
- ups101 11y agotrue, but to be fair, you'd probably also want to introduce variables like $addPhotoBtn, $tweetBtn, $textLengthLbl, etc, to avoid css queries on every keyboard change. That would add to solution length and also introduce a bind-step to avoid stale variables after a dom change. Also, there's the authors very well-placed point that adding a new feature may lead to css query refactoring, eg. when $("textarea") doesn't cut it. I find html refactorings to be nb 1 cause for breaking progressively enhanced solutions like this one, probably bc I suck at naming elements. Lastly, it should be noted that this refactored solution does not contain all the features of the final react solution.
- SlashmanX 11y agoMakes more sense to me to have the "Tweet" button enabled by default and disabled on load by JS. If there's an issue with the JS or it's disabled in the browser or whatever, the button should still work (with server side logic to catch empty Tweets). Right now, if the JS doesn't load you can't Tweet at all. Just a small nitpick I had after thinking about the reasoning behind why the OP had disabled the button in JS rather than the HTML in the first place.