Add new articles

blog_posts/css-code-reviews.md

@@ -0,0 +1,33 @@
+---
+title: How do you review CSS code in Pull Requests?
+shortTitle: CSS code reviews
+type: story
+tags: css,webdev
+author: chalarangelo
+cover: green-css
+excerpt: Reviewing CSS code is a skill that takes time to master. Here are some tips from my personal experience to help you get started.
+firstSeen: 2023-05-21T05:00:00-04:00
+---
+
+Reviewing CSS code is a bit different than reviewing JavaScript code. In fact, many developers pay little attention to CSS, which can lead to problems down the line. Yet, many developers don't know how to review CSS code properly. In this post, we'll go over some of the things you should look for when reviewing CSS code in Pull Requests.
+
+### Visual check
+
+The very first step when reviewing CSS is to check if the **result looks right**. This might mean comparing the end result to a **design mockup** or checking if every interaction behaves according to the animation principles the team has agreed upon. **Responsiveness** is also a key factor to consider, so you should check if the page looks right on **different screen sizes**. The visual check is probably the most straightforward and important step, but unfortunately many developers stop there.
+
+### Code style
+
+Your team should have set up a **linter and formatter** for CSS and, if you haven't, you should do it as soon as possible. This will help you enforce a consistent code style and make the code easier to read and maintain. Provided that's the case, you should check for **conventions** that the linter can't automatically enforce. These often include naming conventions, proper documentation or the use of CSS custom properties in place of hard-coded values.
+
+### Specificity
+
+CSS selectors can be easily abused, causing headaches later down the line. Having clear conventions usually resolves a lot of issues, but things can slip through the cracks. Ensuring specificity is **as low as possible** and that selectors are **not too generic or overly complex** will help increase the code's maintainability.
+
+### Leftovers
+
+In an ideal scenario, the Pull Request author has a clear vision of the CSS they are writing and everything works out perfectly the first time. As you know, that's rarely the case, meaning experimentation and changes will happen during development. As the code changes, some **old code** might hang around without contributing anything to the page. One of the most common examples I've stumbled upon are flexbox-related properties for non-flexbox elements. These take a bit of time to spot, but they can be easily removed, saving you problems in the future.
+
+### Performance
+
+CSS performance is very often overlooked. Simple rules, deduplication and minimum overrides are some of the things that can be done to improve performance. Understandably, this sort of opportunity is **hard to spot**, but it's worth keeping an eye out for. That being said, don't go overboard with performance optimizations. If you're not sure if something is worth it, you should probably leave it as is.
+

blog_posts/javascript-reload-page.md

@@ -0,0 +1,46 @@
+---
+title: How can I use JavaScript to reload the page?
+shortTitle: Reload page
+type: story
+tags: javascript,browser
+author: chalarangelo
+cover: night-tram
+excerpt: Need to reload the current page using JavaScript? Here's the best way to do it, as well as some alternatives.
+firstSeen: 2023-05-14T05:00:00-04:00
+---
+
+### The short answer
+
+Most often than not, `window.location.reload()` is all you need to reload the current page. This method behaves exactly like the **browser's reload button**, using the same cache rules and everything.
+
+```js
+// Reload the page
+window.location.reload();
+```
+
+### The slightly longer answer
+
+While `window.location.reload()` is the most common way to reload a page, there are some nuances that you might need to be aware of.
+
+As stated already, compatibility shouldn't be an issue, so we're not going to delve into that. However, there's a notable oddity concerning the method's arguments. As it turns out, **Firefox** used to support an optional `forceGet` boolean argument, which you might come across in older code. This means that passing a value of `true` to the method would bypass the **browser's cache**.
+
+```js
+// Bypass cache in Firefox
+window.location.reload(true);
+```
+
+Apart from that, `window.location.reload()` will reload the page **keeping POST data** in forms, which might not be desired. In those situations, you might want to assign `window.location.href` to itself to cause a reload. This will cause the page to reload, but will also clear the POST data.
+
+```js
+// Clear POST data
+window.location.href = window.location.href;
+```
+
+This technique also comes with some caveats. For example, if the current **URL contains a hash**, the page won't reload. In this case, you might want to use `String.prototype.split()` to remove the hash from the URL and then assign it to itself.
+
+```js
+// Reload the page, removing the hash from the URL
+window.location.href = window.location.href.split('#')[0];
+```
+
+As you can see, each technique has its pros and cons, so you should choose the one that best suits your needs. That being said, `window.location.reload()` is the most common and reliable way to reload a page, so it's the one you should use most of the time.

blog_posts/js-dynamic-getter-chain-proxy.md

@@ -0,0 +1,48 @@
+---
+title: Chaining dynamic getters using the Proxy object
+shortTitle: Dynamic getter chaining
+type: story
+tags: javascript,object,proxy
+author: chalarangelo
+cover: colorful-rocks
+excerpt: Using the Proxy object, we can create chainable dynamic getters for objects in JavaScript.
+firstSeen: 2023-05-28T05:00:00-04:00
+---
+
+The dawn of ES6 brought about jQuery's fall from grace, as a lot of the conveniences it afforded developers were now available in the language itself. However, jQuery's API design was convenient in many ways that native JavaScript often isn't. One of the most practical things jQuery offered was its ability to chain methods together, minimizing duplication and making code more readable.
+
+Looking at the use case at hand, I thought that I could stitch together a general-purpose solution using JavaScript's `Proxy` object. In fact, I think that the concept of dynamic getters and setters that I described in [my previous post](/articles/s/js-dynamic-getter-setter-proxy) is a great place to start.
+
+To recap, intercepting the behavior of the `get` and `set` traps of a `Proxy` object allows us to create dynamic accessors for objects. This is particularly useful when the shape of the data is not known in advance, or when the value of a property needs to be manipulated before it is returned.
+
+In our scenario, we want each property to be accessed as a function. The function should do one of two things, depending on the argument it receives:
+
+- If the argument is `undefined`, then the property should be returned as-is.
+- If the argument is any other value, the property should be set to the value of the argument and a proxy of the object should be returned.
+
+Given these requirements, we can define the handler's behavior for the `get` trap. All we need to do is check if the argument is `undefined` and choose which behavior to perform. Here's what the code looks like:
+
+```js
+const getHandler = {
+  get: (target, prop) => {
+    return value => {
+      if (typeof value !== 'undefined') {
+        target[prop] = value;
+        return new Proxy(target, getHandler);
+      }
+      return target[prop];
+    };
+  }
+};
+
+const styles = {};
+const proxiedStyles = new Proxy(styles, getHandler);
+
+proxiedStyles.color('#101010').background('#fefefe').margin('4px 8px');
+
+proxiedStyles.color(); // #101010
+proxiedStyles.background(); // #fefefe
+proxiedStyles.margin(); // 4px 8px
+```
+
+As you can see the handler is pretty short and straightforward. The only confusing step is the creation of a new `Proxy` inside the trap. As we don't have a reference to the proxy object itself inside the trap, we need to create a new one. This is necessary because we want to return a new proxy to allow for chaining. If we didn't do this, the proxy would only be able to be used once.