So many articles are written after the fact, and the author either forgets or takes for granted the jumps in logic they made. This article was writ...
For further actions, you may consider blocking this person and/or reporting abuse
Here I am having some knowledge of algorithms and an expensive macbook, but not really getting into open source, I feel ashamed. 😅
This was an excellent post!! Kept me wanting to read more as I went on, especially since I missed your PR being merged. 😅
Small tip, you can use the meta tag instead of devto; more visibility that way.
Looking forward to your next post!
Thanks for the tip! I've changed the tag, every bit of extra SEO counts. I may also be guilty of obsessively looking over dev.to/daolf/-what-is-the-best-tim... to determine the best time to post this haha.
This was a great description of what real world web development problem solving looks like.
It's not a straightforward process, it's not pretty, but it's effective.
I think your creativity in problem solving, perseverance, and also knowing when to step back (to get some sleep) are all things new and experiences devs should take note of.
Thanks for the post!
"expensive macbooks"
YUP! Indeed MacOs disables visual scrollbars by default so it's likely the devs with fancy macbooks who built the site never noticed the issue (just like it never affected me..).
Sometimes building and designing on top of the line hardware can blind us to some issues (same thing happens when designers have 27" apple cinema displays and forget that other people don't, or forget that most people's smartphones process javascript like 5x slower than flagship devices).
Which is to say.. sometimes not having an expensive macbook makes you more valuable as a developer or designer 👍
Which is to say.. fuck yeah diversity!
I've gotten the odd problem of things working great for me, then finding out there's a bug that only affects top-of-the-line, high-resolution, ginormous screens. My font-sizes adjusted as per my CSS @media responsive rules which were based on screen width. The problem was that by adjusting, the last few letters in two of my menu items would be cut off if the extension icon was too close to the end of the browser's toolbar. It was an easy fix, but I would have never known if I hadn't been told about it. Who knew odd screen ratios could screw up a menu?
Well, so right! I got a small resolution screen notebook at home, I have shopping carts at online shops where I am not being able to reach the submit button, because the shopping carts height is higher than my screen is able to show...
On the other hand, I had a bug on a client's website where the logo graphic was inverted. Took me hours to figure out, that the graphic was in the wrong color scheme... CMYK instead of RGB, so the macbook inverted it and the default windows user wouldn't ever noticed this ;)
I use my phone to try and write, but every time the keyboard got focus, it scrolls out of view of the text cursor.
It's quite difficult to write this way! Hopefully the scrolling gets priority for getting fixed.
That sucks! :( Unless someone reports it they won't know there's a problem to be fixed - I suggest making a issue on their github page:
github.com/thepracticaldev/dev.to/...
You can use a screen recording app to make it clear what's happening.
Or you can write out a report by following tip #5:
Maybe you can update the link to the screen recording app, because it is broken :) Thanks.
Fixed, thanks!
Thanks for fixing this bug and such a great story, I really enjoyed hearing how you tackled it step by step
This is a great post @almenon , thanks for walking us through your process of eliminations, the discoveries and the solution.
Really loved reading it :)
There are so many it's not funny anymore 👀
Hahaha that would have been me :P
I enjoyed reading this because of your storytelling
Great post! I love the idea of documenting your process of debugging and solving the issue to make this post. It is a great play by play of your whole process. Great stuff!
Great job on the bug hunt. Now the real question is, why is a 3rd party package required in order to implement an auto-sizing textarea?
My rule of thumb is if the package fits your use case, is more than a couple lines, and has been updated sometime recently, it's probably best to re-use it instead of writing your own code. If you try re-writing the code on your own you will probably discover the situation is more complex than it appears and end up spending more time than you allocated. In this case react-textarea-autosize is two files of code, so I can understand why they used a package.
On the other hand it hasn't been kept up to date, last commit in 2016 and it's 166 commits behind the original repo. I'm not a preact developer so I'm not sure how hard it would be to adapt the original repo for preact. I'm guesing I would just stick with the old preact version. ¯\(ツ)/¯