| const publicPath = 'public'; | |
| // Node os module | |
| // The os module provides a number of operating system-related utility methods. | |
| // It can be accessed using: | |
| const os = require('os'); | |
| // Using a single monolithic configuration file impacts comprehension and | |
| // removes any potential for reusability. | |
| // As the needs of your project grow, you have to figure out the means to manage | |
| // webpack configuration more effectively. |
| const serverRenderedHtml = async (req, res, renderProps) => { | |
| const store = configureStore(); | |
| //call, wait, and set api responses into redux store's state (ghub.io/redux-connect) | |
| await loadOnServer({ ...renderProps, store }); | |
| //render the html template | |
| const template = html( | |
| renderToString( | |
| <Provider store={store} key="provider"> | |
| <ReduxAsyncConnect {...renderProps} /> | |
| </Provider>, |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
| // Promise.all is good for executing many promises at once | |
| Promise.all([ | |
| promise1, | |
| promise2 | |
| ]); | |
| // Promise.resolve is good for wrapping synchronous code | |
| Promise.resolve().then(function () { | |
| if (somethingIsNotRight()) { | |
| throw new Error("I will be rejected asynchronously!"); |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
| if (downloadRatio < 1.0) { | |
| self.debug.log("Download ratio is poor."); | |
| if (current > 0) { | |
| self.debug.log("We are not at the lowest bitrate, so switch down."); | |
| self.manifestExt.getRepresentationFor(current - 1, data).then( | |
| function (representation1) { | |
| self.manifestExt.getBandwidth(representation1).then( | |
| function (oneDownBandwidth) { | |
| self.manifestExt.getRepresentationFor(current, data).then( | |
| function (representation2) { |
#Node - File Paths
##File Paths Node has a path module which can be used to manipulate paths.
###Normalizing Paths Paths can be stored in different ways and it is neccessary to ensure that the path is standardized.
var path = require('path');
path.normalize('/foo/bar//baz/asdf/quux/..');#Introduction
Developing Chrome Extensions is REALLY fun if you are a Front End engineer. If you, however, struggle with visualizing the architecture of an application, then developing a Chrome Extension is going to bite your butt multiple times due the amount of excessive components the extension works with. Here are some pointers in how to start, what problems I encounter and how to avoid them.
Note: I'm not covering chrome package apps, which although similar, work in a different way. I also won't cover the page options api neither the new brand event pages. What I explain covers most basic chrome applications and should be enough to get you started.
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <title>Example</title> | |
| <meta name="description" content="This is just an example"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1"> | |
| <link rel="stylesheet" href="css/main.css"> | |
| </head> | |
| <body data-modules="foobar, lorem/ipsum"> |
