Merge remote-tracking branch 'origin/master'

blog_data/snippetList.json

@@ -8,8 +8,7 @@
         "text": "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:\n\n1. ESLint\n[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.\n\n2.  GitLens\n[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.\n \n3. Debugger for Chrome\n[Debugger for Chrome](https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome) allows you to debug your JavaScript code in Chrome or Chromium. Breakpoints, call stack inspection and stepping inside a function are only some of its features.\n\n4. Bracket Pair Colorizer 2\n[Bracket Pair Colorizer 2](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2) makes reading code faster as it makes matching brackets the same color. This extension for VS Code improves upon its predecessor by providing improved performance.\n\n5. Bookmarks\n[Bookmarks](https://marketplace.visualstudio.com/items?itemName=alefragnani.Bookmarks) is one of those extensions that will significantly reduce your time jumping between different files, as it allows you to save important positions and navigate back to them easily and quickly.\n\n6. TODO Highlight\n[TODO Highlight](https://marketplace.visualstudio.com/items?itemName=wayou.vscode-todo-highlight) simplifies tracking leftover tasks by allowing you to list all of your TODO annotations, as well as adding a handy background highlight to them to make them pop out immediately. \n\n7. Live Server\n[Live Server](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer) gives you an easy way to serve web pages from VS Code, making previewing and debugging a lot easier. One of the core features is the live reload support that many developers are used to.\n\n8. REST Client\n[REST Client](https://marketplace.visualstudio.com/items?itemName=humao.rest-client) allows you to send HTTP requests and view the responses directly in VS Code. This extension supports a wide range of formats and authorization and should work with most setups.\n\n9. One Dark Pro\n[One Dark Pro](https://marketplace.visualstudio.com/items?itemName=zhuangtongfa.Material-theme) is one of the most popular VS Code themes and with very good reason. It provides a clean theme with a nice palette that has great contrast and is very comfortable to use on a daily basis.\n \n10. Fira Code\n[Fira Code](https://github.com/tonsky/FiraCode) is not a traditional VS Code extension and might take a couple more steps to set up, but it's a superb programming font with ligatures that will help you scan code faster once you get used to it.\n\n**Image credit:** [Fotis Fotopoulos](https://unsplash.com/@ffstop?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/code?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",
         "tags": [
           "devtools",
-          "vscode",
+          "vscode"
-          "javascript"
         ]
       },
       "meta": {
@@ -21,15 +20,14 @@
       "type": "snippetListing",
       "title": "An approach to testing stateful React components",
       "attributes": {
-        "text": "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.\n\nMy 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:\n\n```js\ncontext('the component is initialized in a collapsed state', function() {\n  let wrapper;\n  beforeEach(function(){\n    wrapper = mount(<StatefulComponent />);\n  });\n\n  it('component state.expanded is false', function() {\n    expect(wrapper.state('expanded')).to.be.false;\n  });\n});\n```\n\nIn this test, we check if the component's state has `expanded` equal to `false`. Our test will pass, as long as this simple condition is true. It's a very simple test that should be easy to understand even for someone completely unfamiliar with the codebase.\n\nHowever, over time the component's implementation might change. What happens if `expanded` in our state ends up meaning something different? Or worse yet, if it isn't reflected the same way in the interface?\n\nEnter my \"Eureka!\" moment:\n\n> The application's UI should always be considered the result of combining the component's props and state.\n\nThe above statement implies that a component's state can be considered a black box while testings, an abstraction layer that should not be accessed unless absolutely necessary. So, instead of the test presented above, we should be doing something more like this:\n\n```js\ncontext('the component is initialized in a collapsed state', function() {\n  let wrapper;\n  beforeEach(function(){\n    wrapper = mount(<StatefulComponent />);\n  });\n\n  it('component does not have the expanded class', function() {\n    expect(wrapper.find('div').hasClass('expanded')).to.be.false;\n  });\n});\n```\n\nOur test is still easy to read and understand, but it's a better test in general. \n\nDirectly checking the DOM instead of the component's state, we directly provide information about the component's output to future code authors, instead of asking them to keep the existing implementation intact. It seems like a better way to document the component and it's easier to track future changes should someone refactor the UI in such a way that the DOM representation of the component is altered.\n\n**Image credit:** [Evan Clark](https://unsplash.com/@evanrclark?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",
+        "text": "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.\n\nMy 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:\n\n```js\ncontext('the component is initialized in a collapsed state', function() {\n  let wrapper;\n  beforeEach(function(){\n    wrapper = mount(<StatefulComponent />);\n  });\n\n  it('component state.expanded is false', function() {\n    expect(wrapper.state('expanded')).to.be.false;\n  });\n});\n```\n\nIn this test, we check if the component's state has `expanded` equal to `false`. Our test will pass, as long as this simple condition is true. It's a very simple test that should be easy to understand even for someone completely unfamiliar with the codebase.\n\nHowever, over time the component's implementation might change. What happens if `expanded` in our state ends up meaning something different? Or worse yet, if it isn't reflected the same way in the interface?\n\nEnter my \"Eureka!\" moment:\n\n> The application's UI should always be considered the result of combining the component's props and state.\n\nThe above statement implies that a component's state can be considered a black box while testings, an abstraction layer that should not be accessed unless absolutely necessary. So, instead of the test presented above, we should be doing something more like this:\n\n```js\ncontext('the component is initialized in a collapsed state', function() {\n  let wrapper;\n  beforeEach(function(){\n    wrapper = mount(<StatefulComponent />);\n  });\n\n  it('component does not have the expanded class', function() {\n    expect(wrapper.find('div').hasClass('expanded')).to.be.false;\n  });\n});\n```\n\nOur test is still easy to read and understand, but it's a better test in general. \n\nBy directly checking the DOM instead of the component's state, we provide information about the component's output to future code authors, instead of asking them to keep the existing implementation intact. It seems like a better way to document the component and it's easier to track future changes should someone refactor the UI in such a way that the DOM representation of the component is altered.\n\n**Image credit:** [Evan Clark](https://unsplash.com/@evanrclark?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",
         "tags": [
           "react",
-          "javascript",
           "testing"
         ]
       },
       "meta": {
-        "hash": "fbf63d2634248d8339605ab85da3f2ffc90024172db809a189fc1d926a784579"
+        "hash": "8a68806114f98a5da74a0785b6ccb29ed19398f9d1ecfb48ee8a6e195b6f322a"
       }
     }
   ],

blog_data/snippets.json

@@ -13,40 +13,38 @@
         "text": "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:\n\n1. ESLint\n[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.\n\n2.  GitLens\n[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.\n \n3. Debugger for Chrome\n[Debugger for Chrome](https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome) allows you to debug your JavaScript code in Chrome or Chromium. Breakpoints, call stack inspection and stepping inside a function are only some of its features.\n\n4. Bracket Pair Colorizer 2\n[Bracket Pair Colorizer 2](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2) makes reading code faster as it makes matching brackets the same color. This extension for VS Code improves upon its predecessor by providing improved performance.\n\n5. Bookmarks\n[Bookmarks](https://marketplace.visualstudio.com/items?itemName=alefragnani.Bookmarks) is one of those extensions that will significantly reduce your time jumping between different files, as it allows you to save important positions and navigate back to them easily and quickly.\n\n6. TODO Highlight\n[TODO Highlight](https://marketplace.visualstudio.com/items?itemName=wayou.vscode-todo-highlight) simplifies tracking leftover tasks by allowing you to list all of your TODO annotations, as well as adding a handy background highlight to them to make them pop out immediately. \n\n7. Live Server\n[Live Server](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer) gives you an easy way to serve web pages from VS Code, making previewing and debugging a lot easier. One of the core features is the live reload support that many developers are used to.\n\n8. REST Client\n[REST Client](https://marketplace.visualstudio.com/items?itemName=humao.rest-client) allows you to send HTTP requests and view the responses directly in VS Code. This extension supports a wide range of formats and authorization and should work with most setups.\n\n9. One Dark Pro\n[One Dark Pro](https://marketplace.visualstudio.com/items?itemName=zhuangtongfa.Material-theme) is one of the most popular VS Code themes and with very good reason. It provides a clean theme with a nice palette that has great contrast and is very comfortable to use on a daily basis.\n \n10. Fira Code\n[Fira Code](https://github.com/tonsky/FiraCode) is not a traditional VS Code extension and might take a couple more steps to set up, but it's a superb programming font with ligatures that will help you scan code faster once you get used to it.\n\n**Image credit:** [Fotis Fotopoulos](https://unsplash.com/@ffstop?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/code?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",
         "tags": [
           "devtools",
-          "vscode",
+          "vscode"
-          "javascript"
         ]
       },
       "meta": {
         "hash": "2dd00656f3a19b08dd10877431101751009c00b0658dc5d3acab61e11fea21e3",
         "firstSeen": "1577090516",
-        "lastUpdated": "1579161118",
+        "lastUpdated": "1579265244",
-        "updateCount": 4,
+        "updateCount": 5,
         "authorCount": 2
       }
     },
     {
       "id": "testing-stateful-ui-components",
       "title": "An approach to testing stateful React components",
-      "type": "blog.post",
+      "type": "blog.story",
       "attributes": {
         "fileName": "testing-stateful-ui-components.md",
         "cover": "blog_images/testing-stateful-ui-components.jpg",
         "authors": [
           "chalarangelo"
         ],
-        "text": "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.\n\nMy 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:\n\n```js\ncontext('the component is initialized in a collapsed state', function() {\n  let wrapper;\n  beforeEach(function(){\n    wrapper = mount(<StatefulComponent />);\n  });\n\n  it('component state.expanded is false', function() {\n    expect(wrapper.state('expanded')).to.be.false;\n  });\n});\n```\n\nIn this test, we check if the component's state has `expanded` equal to `false`. Our test will pass, as long as this simple condition is true. It's a very simple test that should be easy to understand even for someone completely unfamiliar with the codebase.\n\nHowever, over time the component's implementation might change. What happens if `expanded` in our state ends up meaning something different? Or worse yet, if it isn't reflected the same way in the interface?\n\nEnter my \"Eureka!\" moment:\n\n> The application's UI should always be considered the result of combining the component's props and state.\n\nThe above statement implies that a component's state can be considered a black box while testings, an abstraction layer that should not be accessed unless absolutely necessary. So, instead of the test presented above, we should be doing something more like this:\n\n```js\ncontext('the component is initialized in a collapsed state', function() {\n  let wrapper;\n  beforeEach(function(){\n    wrapper = mount(<StatefulComponent />);\n  });\n\n  it('component does not have the expanded class', function() {\n    expect(wrapper.find('div').hasClass('expanded')).to.be.false;\n  });\n});\n```\n\nOur test is still easy to read and understand, but it's a better test in general. \n\nDirectly checking the DOM instead of the component's state, we directly provide information about the component's output to future code authors, instead of asking them to keep the existing implementation intact. It seems like a better way to document the component and it's easier to track future changes should someone refactor the UI in such a way that the DOM representation of the component is altered.\n\n**Image credit:** [Evan Clark](https://unsplash.com/@evanrclark?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",
+        "text": "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.\n\nMy 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:\n\n```js\ncontext('the component is initialized in a collapsed state', function() {\n  let wrapper;\n  beforeEach(function(){\n    wrapper = mount(<StatefulComponent />);\n  });\n\n  it('component state.expanded is false', function() {\n    expect(wrapper.state('expanded')).to.be.false;\n  });\n});\n```\n\nIn this test, we check if the component's state has `expanded` equal to `false`. Our test will pass, as long as this simple condition is true. It's a very simple test that should be easy to understand even for someone completely unfamiliar with the codebase.\n\nHowever, over time the component's implementation might change. What happens if `expanded` in our state ends up meaning something different? Or worse yet, if it isn't reflected the same way in the interface?\n\nEnter my \"Eureka!\" moment:\n\n> The application's UI should always be considered the result of combining the component's props and state.\n\nThe above statement implies that a component's state can be considered a black box while testings, an abstraction layer that should not be accessed unless absolutely necessary. So, instead of the test presented above, we should be doing something more like this:\n\n```js\ncontext('the component is initialized in a collapsed state', function() {\n  let wrapper;\n  beforeEach(function(){\n    wrapper = mount(<StatefulComponent />);\n  });\n\n  it('component does not have the expanded class', function() {\n    expect(wrapper.find('div').hasClass('expanded')).to.be.false;\n  });\n});\n```\n\nOur test is still easy to read and understand, but it's a better test in general. \n\nBy directly checking the DOM instead of the component's state, we provide information about the component's output to future code authors, instead of asking them to keep the existing implementation intact. It seems like a better way to document the component and it's easier to track future changes should someone refactor the UI in such a way that the DOM representation of the component is altered.\n\n**Image credit:** [Evan Clark](https://unsplash.com/@evanrclark?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",
         "tags": [
           "react",
-          "javascript",
           "testing"
         ]
       },
       "meta": {
-        "hash": "fbf63d2634248d8339605ab85da3f2ffc90024172db809a189fc1d926a784579",
+        "hash": "8a68806114f98a5da74a0785b6ccb29ed19398f9d1ecfb48ee8a6e195b6f322a",
         "firstSeen": "1579161498",
-        "lastUpdated": "1579161498",
+        "lastUpdated": "1579265244",
-        "updateCount": 2,
+        "updateCount": 3,
         "authorCount": 2
       }
     }