Merge pull request #10 from nick-w-nick/spelling-fixes
Fixing spelling errors across multiple snippets
This commit is contained in:
@ -44,10 +44,10 @@ Replace `<my-snippet-name>` with the name of the snippet you are adding.
|
||||
- Snippet types must be one of the following: `story`, `list` or `question`.
|
||||
- Snippet titles must be short enough and correspond to the type of the snippet. Titles for each type must follow the format of previous snippets (e.g. `The trickiest thing about X` for a story, `X things that are awesome` for a list, `How do I do X in Y?` for a question).
|
||||
- Snippet types must be one of the following: `story`, `list` or `question`.
|
||||
- Snippet tags must be comma-separated. You are allowed to specify a single language tag (e.g. `react` or `javascript`), preferrably as the first tag.
|
||||
- Snippet tags must be comma-separated. You are allowed to specify a single language tag (e.g. `react` or `javascript`), preferably as the first tag.
|
||||
- Snippet authors must be comma-separated and should be added in JSON format as seen in `blog_data/blog_authors.json`.
|
||||
- Snippet covers must be added inside the `blog_images` directory and have the exact same name as the snippet filename. Snippet covers must be Unsplash images of appropriate theme and content and must be credited accordingly at the end of the snippet.
|
||||
- Snippet excerpts must be a very short description of the snippet's content, up to 180 characters in length. The excerpt must contain some of the main keywords and a general intro to the snippet, as it will be used for social sharing and previewing the snippet iteself.
|
||||
- Snippet excerpts must be a very short description of the snippet's content, up to 180 characters in length. The excerpt must contain some of the main keywords and a general intro to the snippet, as it will be used for social sharing and previewing the snippet itself.
|
||||
- Snippets that are of the `list` type must be written as such, check previously submitted snippets for more details.
|
||||
- Snippet code and examples must be enclosed in appropriate, language-tagged blocks, be short and use modern techniques and features. Also make sure to test your code before submitting. Always use soft tabs (2 spaces), never hard tabs.
|
||||
- Snippets with code examples should follow the related language repository's guidelines in regards to code formatting and conventions.
|
||||
|
||||
@ -10,7 +10,7 @@ excerpt: VS Code is steadily gaining popularity among developers. Here are 10 es
|
||||
Developers will most likely argue for the rest of eternity about the most productive code editor and the best extensions. Here are my personal extension preferences for VS Code as a JavaScript developer:
|
||||
|
||||
1. ESLint
|
||||
[ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) turns the popular JavaScrpt linter into an extension of VS Code. It automatically reads your linting configuration, identifies problems and even fixes them for you, if you want.
|
||||
[ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) turns the popular JavaScript linter into an extension of VS Code. It automatically reads your linting configuration, identifies problems and even fixes them for you, if you want.
|
||||
|
||||
2. GitLens
|
||||
[GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) is a very powerful collaboration tool for VS Code. It provides many useful tools for git such as blame, code authorship, activity heatmaps, recent changes, file history and even commit search.
|
||||
|
||||
@ -29,6 +29,6 @@ Any kind of `<input>` element should be labelled appropriately, using either a `
|
||||
Responsiveness is often thought in terms of screen size or mobile vs desktop, but there are many different devices where a user could browse your website. Try catering to any and all of them by providing ways to navigate and use your application via mouse, keyboard, thumb or any combination of the three.
|
||||
|
||||
8. Organize your content
|
||||
A website's layout should be easy to scan, understand and find the content that is relevant to the user. Good organization with clear sections and properly groupped content provides a better user experience for all users, regardless of device or accessibility needs.
|
||||
A website's layout should be easy to scan, understand and find the content that is relevant to the user. Good organization with clear sections and properly grouped content provides a better user experience for all users, regardless of device or accessibility needs.
|
||||
|
||||
**Image credit:** [AbsolutVision](https://unsplash.com/@freegraphictoday?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
|
||||
|
||||
@ -13,7 +13,7 @@ Working from home (also known as remote work) seems like a great alternative to
|
||||
Working from home has its perks, but nothing beats a well-designed office space where everything is set up with only one purpose in mind: working. Figure out your home office, experiment with different settings and understand what works best for you as soon as possible. An ideal working space is comfortable, quiet and has the right equipment for you.
|
||||
|
||||
2. Establish ground rules
|
||||
Most likely you are not living alone, so you have to establish some ground rules with your roomate or significant other. It's up to you to drive the point home that during working hours you are, for the most part, not home. Sure, you can answer the door if you expect a delivery, but that's pretty much as far as you can go. People should not bother you during working hours, unless absolutely necessary, as small distractions pile up fast.
|
||||
Most likely you are not living alone, so you have to establish some ground rules with your roommate or significant other. It's up to you to drive the point home that during working hours you are, for the most part, not home. Sure, you can answer the door if you expect a delivery, but that's pretty much as far as you can go. People should not bother you during working hours, unless absolutely necessary, as small distractions pile up fast.
|
||||
|
||||
3. Inform others of your availability
|
||||
It's important to let people know that you are online and working or that you are taking a short break for lunch. Remember that you are still part of a team that requires coordination and others probably depend on your work to some extent. Remember to update your status as necessary to make collaboration easier.
|
||||
@ -22,7 +22,7 @@ It's important to let people know that you are online and working or that you ar
|
||||
Working from home can lead to feelings of loneliness, disconnect, isolation which can quickly spin out of control and lead to depression. Communicate with people on your team as if you were in the same room. A healthy amount of communication will help you feel more like you are all working together rather than each one on their own.
|
||||
|
||||
5. Be your best professional self
|
||||
Nobody might be watching you at home, so you can theoretically slack off as much as you like in your pajamas, but that's not very professional. Try to dress appropriately in case you join a video call and behave professionaly, so no inappropriate websites or hours upon hours of checking social media. Ask yourself if someone in a shared office space would do whatever it is you are doing and, if the answer is no, stop doing it.
|
||||
Nobody might be watching you at home, so you can theoretically slack off as much as you like in your pajamas, but that's not very professional. Try to dress appropriately in case you join a video call and behave professionally, so no inappropriate websites or hours upon hours of checking social media. Ask yourself if someone in a shared office space would do whatever it is you are doing and, if the answer is no, stop doing it.
|
||||
|
||||
6. Plan your daily and weekly tasks
|
||||
Having a coherent working plan helps you organize your time and prioritize important tasks above trivial ones. It also helps to put things into perspective and have a general idea of what other people on the team are working on. Plan ahead of time together with your team and keep each other posted on the progress of each task. Short term plans help you get through the day, long term plans help everyone meet their deadlines.
|
||||
|
||||
@ -9,8 +9,8 @@ excerpt: Learn everything you need to know about promises and asynchronous JavaS
|
||||
|
||||
### Promise basics
|
||||
|
||||
- **Promises** start in a **pending state**, neither fullfiled or rejected.
|
||||
- When the operation is completed, a promise will become **fullfiled with a value**.
|
||||
- **Promises** start in a **pending state**, neither fulfilled or rejected.
|
||||
- When the operation is completed, a promise will become **fulfilled with a value**.
|
||||
- If the operation fails, a promise will get **rejected with an error**.
|
||||
|
||||
### Creating promises
|
||||
@ -72,7 +72,7 @@ promisedOperation()
|
||||
|
||||
- `Promise.all()` turns an array of promises into a promise of an array.
|
||||
- If any promise is rejected, the error will pass through.
|
||||
- `Promise.race()` passes throuh the first settled promise.
|
||||
- `Promise.race()` passes through the first settled promise.
|
||||
|
||||
```js
|
||||
Promise
|
||||
|
||||
@ -89,7 +89,7 @@ fibonacciNumber(4);
|
||||
// [CALC] Computed and stored value for 4: 3
|
||||
```
|
||||
|
||||
As you can see in the example above, the value for each `n` is only computed once. While the Fibonacci sequence doesn't require any costly calculations, this could make a huge difference for a more computationally expensive problem. It will also be a lot more noticable for higher values of `n` where the number of calculations will increase singificantly.
|
||||
As you can see in the example above, the value for each `n` is only computed once. While the Fibonacci sequence doesn't require any costly calculations, this could make a huge difference for a more computationally expensive problem. It will also be a lot more noticeable for higher values of `n` where the number of calculations will increase significantly.
|
||||
|
||||
### Using iteration
|
||||
|
||||
@ -114,7 +114,7 @@ fibonacciNumber(4);
|
||||
// [CALC] i = 3: r = 1, l = 2, s = 3
|
||||
```
|
||||
|
||||
The iterative solution above makes the same calculations as the memoized one, however it performas better due to two key reasons. First of all, there is no cache, which would take up space in memory, making the latter implementation require fewer resources. Similarly, as there are no recursive calls or checks for cache hits, the code performs better and requires fewer resources to execute.
|
||||
The iterative solution above makes the same calculations as the memoized one, however it performs better due to two key reasons. First of all, there is no cache, which would take up space in memory, making the latter implementation require fewer resources. Similarly, as there are no recursive calls or checks for cache hits, the code performs better and requires fewer resources to execute.
|
||||
|
||||
However, you have to bear in mind what the actual use cases of your recursive code are and be very careful how you optimize them. Memoization can be a more powerful tool if a recursive function is called multiple times with different arguments, as its cache persists between calls, while iteration can be faster for recursive computations that are used less frequently. Always pay attention to your code and optimize for the cases you know or anticipate to be more common.
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ Cookies store small amounts of data that has to be sent back to the server with
|
||||
|
||||
### Local storage
|
||||
|
||||
Local storage stores a larger amount of data on the client's computer in a key-value pair format and has no expiration date. Data is never transferred to the server and is accesible via JavaScript and HTML5.
|
||||
Local storage stores a larger amount of data on the client's computer in a key-value pair format and has no expiration date. Data is never transferred to the server and is accessible via JavaScript and HTML5.
|
||||
|
||||
- Capacity: 10MB
|
||||
- Accessible from: Any window
|
||||
|
||||
@ -7,7 +7,7 @@ cover: blog_images/orange-flower.jpg
|
||||
excerpt: Learn how to use CSS pseudo-classes to style an element based on changes to its state.
|
||||
---
|
||||
|
||||
CSS pseudo-classes provide a way to style elements, based on changes to their state. For example, `:hover` can be used to apply additiona styles to an element when the user's pointer hovers over it.
|
||||
CSS pseudo-classes provide a way to style elements, based on changes to their state. For example, `:hover` can be used to apply additional styles to an element when the user's pointer hovers over it.
|
||||
|
||||
Pseudo-classes let you apply styles to elements in relation to the content of the document tree (e.g. `:first-child`), external factors such as the history of the navigator (e.g. `:visited`), the status of their content (e.g. `:checked`) or the position of the mouse (e.g. `:hover`).
|
||||
|
||||
|
||||
@ -21,6 +21,6 @@ Co-authored-by: another-name <another-name@example.com>"
|
||||
|
||||
- To correctly attribute a commit to a co-author, you must use the email associated with their GitHub account.
|
||||
- If a person's email is private, you can use their GitHub-provided `no-reply` email.
|
||||
- Leave one or preferrably two empty lines before any `Co-authored-by` trailers.
|
||||
- Leave one or preferably two empty lines before any `Co-authored-by` trailers.
|
||||
|
||||
**Image credit:** [Taylor Simpson](https://unsplash.com/@taylorgsimpson?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
|
||||
|
||||
@ -9,7 +9,7 @@ excerpt: Learn the differences between JavaScript ES6 arrow functions and regula
|
||||
|
||||
### Arrow functions
|
||||
|
||||
JavaScript ES6 introduced the concept of arrow functions, a new way to define and write functions. While they might seem like a syntactic sugar on top of regular functions, they have a key difference which lies in the way the `this` context is bound. I will not go into a lot of detail in this article, however I strongly suggest you read [Understanding the "this" keyword in JavaScript](/blog/s/javascript-this) before continuing. To summarize what the afforementioned blog post explains in more detail:
|
||||
JavaScript ES6 introduced the concept of arrow functions, a new way to define and write functions. While they might seem like a syntactic sugar on top of regular functions, they have a key difference which lies in the way the `this` context is bound. I will not go into a lot of detail in this article, however I strongly suggest you read [Understanding the "this" keyword in JavaScript](/blog/s/javascript-this) before continuing. To summarize what the aforementioned blog post explains in more detail:
|
||||
|
||||
> Arrow functions do not have their own bindings for `this`, resulting in `this` retaining the value of the enclosing lexical context's `this`.
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ excerpt: Naming conventions, while not easy to enforce, make code easier to read
|
||||
|
||||
- Names are case-sensitive, lowercase and uppercase are different.
|
||||
- Start class names with a capital letter, use `PascalCase` for names.
|
||||
- Use descriptive names, explaining the funcionality of the class.
|
||||
- Use descriptive names, explaining the functionality of the class.
|
||||
- Components, which are used in frontend frameworks follow the same rules.
|
||||
|
||||
### Private
|
||||
|
||||
@ -38,7 +38,7 @@ Apart from cleaner code, this operator might spare us some headaches related to
|
||||
```js
|
||||
const config = getServerConfig();
|
||||
|
||||
// Without nullish coallescing
|
||||
// Without nullish coalescing
|
||||
const port = config.server.port || 8888;
|
||||
// Oops! This will be true even if we pass it false
|
||||
const wrongkeepAlive = config.server.keepAlive || true;
|
||||
@ -47,7 +47,7 @@ const keepAlive =
|
||||
(config.server.keepAlive !== null & config.server.keepAlive !== undefined)
|
||||
? config.server.keepAlive : true;
|
||||
|
||||
// With nullish coallescing
|
||||
// With nullish coalescing
|
||||
const port = config.server.port ?? 8888;
|
||||
// This works correctly
|
||||
const keepAlive = config.server.keepAlive ?? true;
|
||||
|
||||
@ -9,7 +9,7 @@ excerpt: One of the most commonly asked JavaScript interview questions is about
|
||||
|
||||
Before your JavaScript code is executed, it is first parsed and compiled. During the _compile_ phase, variable and function declarations are put into memory, which is called **hoisting**.
|
||||
|
||||
Note that only declarations are hoisted, not initializations, meaning that if a variable is declared and initialized after using it, its value will not be initialized. This is an oversimplificatin of the situation, so let's take a look at the different cases:
|
||||
Note that only declarations are hoisted, not initializations, meaning that if a variable is declared and initialized after using it, its value will not be initialized. This is an oversimplification of the situation, so let's take a look at the different cases:
|
||||
|
||||
### function
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ excerpt: Take a deeper dive into React's rendering process and understand how to
|
||||
|
||||
### Optimization opportunities
|
||||
|
||||
As we've seen in the [previous blog post](/blog/s/react-rendering-basics), **rendering** is React's way of knowing if it needs to make changes in the DOM, but there are certain cases where work and calculations performed during the **render phase** can be a wasted effort. After all, if a component's render output is indentical, there will be no DOM updates, thus the work wasn't necessary.
|
||||
As we've seen in the [previous blog post](/blog/s/react-rendering-basics), **rendering** is React's way of knowing if it needs to make changes in the DOM, but there are certain cases where work and calculations performed during the **render phase** can be a wasted effort. After all, if a component's render output is identical, there will be no DOM updates, thus the work wasn't necessary.
|
||||
|
||||
Render output should always be based on the current combination of `props` and `state`, so it is possible to know ahead of time if a component's render output will be the same so long as its `props` and `state` remain unchanged. This is the key observation on top of which optimizing React rendering is based, as it hinges on our code doing less work and skipping component rendering when possible.
|
||||
|
||||
@ -33,7 +33,7 @@ All of these techniques use **shallow equality** for comparisons. Skipping rende
|
||||
|
||||
Passing new references as `props` to a child component doesn't usually matter, as it will re-render regardless when the parent changes. However, if you are trying to optimize a child component's rendering by checking if its `props` have changed, passing new references will cause a render. This behavior is ok if the new references are updated data, but if it's a new reference to the same callback function passed down by the parent, it's rather problematic.
|
||||
|
||||
This is less of an issue in class components, as they have instance methods whose references don't change, although any sort of generated callbacks passed down to a component's chidren can result in new references. As far as function components are concerned, React provides the `useMemo` hook for memoizing values, and the `useCallback` hook specifically for memoizing callbacks.
|
||||
This is less of an issue in class components, as they have instance methods whose references don't change, although any sort of generated callbacks passed down to a component's children can result in new references. As far as function components are concerned, React provides the `useMemo` hook for memoizing values, and the `useCallback` hook specifically for memoizing callbacks.
|
||||
|
||||
`useMemo` and `useCallback` can provide performance benefits but, as with any other memoization usage, it's important to think about their necessity and the net benefit they provide in the long run. A good rule of thumb is to consider using them for pure functional components that re-render often with the same `props` and/or might do heavy calculations and avoid them elsewhere.
|
||||
|
||||
@ -41,7 +41,7 @@ This is less of an issue in class components, as they have instance methods whos
|
||||
|
||||
**React Developer Tools** provide a handy **Profiler** tab that allows you to visualize and explore the rendering process of your React applications. Under this tab, you will find a settings icon which will allow you to _Highlight updates when components render_, as well as _Record why each component rendered while profiling_ - I highly suggest ticking both of them. Recording the initial render and re-renders of the website can provide invaluable insights about the application's bottlenecks and issues and also highlight optimization opportunities (often using one of the techniques described above).
|
||||
|
||||
Finally, remember that React's development builds are significantly slower than production builds, so take all the measurements you see with a grain of salt as absolute times in development are not a valuable metric. Identifying unnecessary renders, memoization and optimization opportunites, as well as potential bottlenecks is where you should focus.
|
||||
Finally, remember that React's development builds are significantly slower than production builds, so take all the measurements you see with a grain of salt as absolute times in development are not a valuable metric. Identifying unnecessary renders, memoization and optimization opportunities, as well as potential bottlenecks is where you should focus.
|
||||
|
||||
[Continue on React rendering state](/blog/s/react-rendering-state)
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ excerpt: Testing React components that update asynchronously with React Testing
|
||||
|
||||
Recently, while working on our latest side-project, [boardeaux](https://github.com/Trinityyi/boardeaux), we started using the [React DnD library](https://react-dnd.github.io/react-dnd), as we wanted to implement a multi-container drag and drop system with cards.
|
||||
|
||||
After spending the better part of a day implementing the functionality, we decided to add some tests to make sure everything will keep working as expected. In the afforementioned project, we use [React Testing Library](https://testing-library.com/docs/react-testing-library/intro) to write tests for our components.
|
||||
After spending the better part of a day implementing the functionality, we decided to add some tests to make sure everything will keep working as expected. In the aforementioned project, we use [React Testing Library](https://testing-library.com/docs/react-testing-library/intro) to write tests for our components.
|
||||
|
||||
While testing the drag functionality, we came across a very stubborn test. Here's a simplified version of our `Card` component:
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ cover: blog_images/testing-stateful-ui-components.jpg
|
||||
excerpt: Testing stateful React components is by no means a difficult task, but did you know there is an elegant solution that doesn't involve testing state directly?
|
||||
---
|
||||
|
||||
Some time ago, I was tasked with writing tests for a handful of React components, an otherwise mundane and uninspiring task, that somehow ended with a "Eureka!" moment for me. The specifics of the project and its components are of little importanc, however the key detail is that I was working with stateful React components that are used daily by a large team and, as such, are refactored and updated quite often.
|
||||
Some time ago, I was tasked with writing tests for a handful of React components, an otherwise mundane and uninspiring task, that somehow ended with a "Eureka!" moment for me. The specifics of the project and its components are of little importance, however the key detail is that I was working with stateful React components that are used daily by a large team and, as such, are refactored and updated quite often.
|
||||
|
||||
My initial approach consisted of writing some simple tests, such as checking if the component is rendered properly and if certain events fire appropriately. In doing so, I was comparing state directly with the result I was expecting, having the component's code right next to my assertions. Of course, this isn't bad by anyone's standards, but for a codebase with many moving parts, it is not the greatest idea. Let me show you an example why:
|
||||
|
||||
|
||||
@ -4,10 +4,10 @@ type: story
|
||||
tags: webdev
|
||||
authors: chalarangelo
|
||||
cover: blog_images/camera-zoom.jpg
|
||||
excerpt: Using the viewport meta tag incorrectly can harm your website's accesibility. Learn how to prevent problems with this handy guide.
|
||||
excerpt: Using the viewport meta tag incorrectly can harm your website's accessibility. Learn how to prevent problems with this handy guide.
|
||||
---
|
||||
|
||||
Using the `"viewport"` meta tag incorrectly can cause some serious accessibility issues for peole with low vision.
|
||||
Using the `"viewport"` meta tag incorrectly can cause some serious accessibility issues for people with low vision.
|
||||
|
||||
The most common and, for the vast majority of cases, correct setup for said tag looks something like the first example below. However, there are websites that might do something like the second example, employing `maximum-scale=1.0` as part of their meta tag:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user