Pokémon Checker Web Application

Static HTML vs HTML created with JavaScript

I wish I would have realized right from the beginning, that refactoring was a given and planned for Achievement 1, and nothing to stress about. When bringing in modules late in the process, refactoring code to have it working again is natural. Not fully understanding this right away, I found the process of repeatedly re-writing/creating/generating a lot of HTML elements, class names, attributes, content, slightly confusing and complicated.

An example: When I started the modal, per requirement I needed to create/generate a lot of HTML elements (class names, attributes, content) with JavaScript. When later the Bootstrap Modal component came in, it wasn't clear what was expected (and made sense!) to still have static and what to generate dynamically. So during implementation, HTML and CSS (and JavaScript) turned out to be a non-functional, badly named hot mess, and I needed some time to figure out the cleanest working set-up. All of this led to refactoring HTML, JavaScript and CSS not only once.

Solution: Achievement 1 consisted of 11 exercises, where working from task to task led to the completion of the Pokémon Checker web application, so feeling challenged was part of the learning curve to understand DOM manipulation and to handle refactoring. Yes, refactoring was time consuming, at the same time the code benefit from it as it became cleaner and easier to understand.

There's the additional takeaway of being wary of to what extend one should create/generate content with JavaScript. The next time I encounter something like this, I would thoroughly check feature requests, make up my mind really early in the process about how my HTML needs to be structured, what kind of functionality needs to be included.

Polyfills

Using polyfills for promises and fetch to support IE was a challenge, as it was a bit of a messy explanation and process why to download and use two very specific files.

Solution: If you need to support older browsers (IE), you need to put in the work. If this would be the case in the future especially regarding IE, I would always discuss approaches/performance (!) with my team, PM/PO, stakeholders, to find the best working solution.

Bootstrap components & Bootstrap CSS

General CSS styling was needed before any of the Bootstrap components came in, so as soon as they came in, I needed to take back all of my previously set styles to figure out what Bootstrap brings out of the box, how to configure that, how to bring back previous styles that still were missing.

The possibility to spend time on going through the Bootstrap documentation to find out how to configure modules to achieve a certain style/behavior was really limited.

Solution: Going through the 11 exercises, working from task to task, it again was part of the learning curve to understand how to incorporate Bootstrap modals into an already existing legacy code. As refactoring was needed not only once, I took this as an opportunity to properly rename functions, class names having BEM in mind, and to check if the HTML structure in general makes sense.

In the future I would implement desired default modules first to find out what comes out of the box and would definitely take the time to go through documentation. Only then I would either adapt configuration/theming or add own CSS styling - or both.

jQuery

Let's just say that I am not a fan and implementing it felt challenging ;)

Per requirement, jQuery only explicitly needed to be used in the showModal function. In my opinion using it only there makes the scripts.js messy. I still deliberately decided to not refactor the rest of vanilla JavaScript to jQuery.

Solution: Not using jQuery? Just kidding, I know that one can encounter it in legacy code. Personally, I would rather not use it even though it makes coding life subjectively easier through writing lesser code. After all, it's another JavaScript library that is thrown at a project (performance!), with functionality that could probably be achieved with vanilla JavaScript. With the use of jQuery there's too much happening behind the curtains I would rather know, understand and being able to debug.

Formatting and linting with Prettier and ESLint

This was a tough one, as I couldn't get the required combination of Prettier and ESLint to properly run and format. Formatting with Prettier was no problem. ESLint did not work. Configuration of both stopped the formatting of JavaScript files.

As I had some other formatter extensions in Visual Studio Code before, I sensed that there might be an interference between all of them, especially maybe with SCSS Formatter. I also found out that I do not need Prettier at all, as Visual Studio Code brings code formatting for HTML, CSS/SCSS and JavaScript out of the box.

It took me a bit to figure out how to best structure my bug fixing approach and to make peace with the fact that the time it would take to fix this needed to be invested.

A first step was to understand that this bug fixing was actually two parts: one part being my personal preference how to code and format (still following common rules!), the other part being how to work in a work environment/team that has certain formatting and linting rules configured.

Solution: As properly formatting is crucial and as I generally did not trust my (user) settings in Visual Studio Code any longer, I decided to do a harsh reset.

In Visual Studio Code, I:

• deleted all of the content in my user settings.json, except for a last pair of { }
• uninstalled all of my Visual Studio Extensions
• carefully brought back the customized workspace/editor/terminal/formatting settings in my user settings.json
• carefully re-installed the Visual Studio Code extensions I need, having a closer look at what they actually DO, this included the ESLint Visual Studio Code extension

In the Pokémon Checker web application, I:

• deleted/uninstalled Prettier, ESLint and configs off of the project
• ran npm install eslint again, to have it in the workspace folder and NOT globally
• re-introduced an .eslintrc with a basic config
• researched and introduced an .editorconfig with a most global configuration to achieve a common code formatting for hypothetical collaborations

Even if being the last exercise of Achievement 1 and - looking at it - a rather small one, this was a huge wake-up call regarding the importance of formatting and linting, especially when it comes to working on a project in a team. I am more than ever aware of having this clarified and set up before writing one line of code in a shared project.