Can't see tfa/site from work... but not sure I'd put this out there... it's ripe for an injection attack, and there are some relatively small markdown libraries that run fine in the browser, and on the server.
I usually go a couple steps further, which is to fully copy the bootstrap.scss main file as well as variables.scss ... I'll update the bootstrap.scss copy to point to the local variables... I've done mixins in the past but never actually found myself changing existing ones. I'll include my own mixins that references the original.
In this way, I have...
/styles/root.scss
includes bootstrap.scss
/styles/bootstrap.scss
references local vars and mixins, rest from bootstrap
/styles/_variables.scss
copy of bootstrap variables
/styles/_mixins.scss
reference bootstrap's mixins
root is included at the top of the project... Other components will have a .scss next to the component that may include variables and/or mixins as needed.
This way I can have my globals, and what I need inline. Beyond all of this, it's easier to comment out parts of bootstrap I'm not using. As to copying variables.scss, this is because I sometimes find it hard to remember what should/can be replaced. I also will usually adjust the font bases, as well as some of the colors and styling choices in variables directly.
In the end it's a much cleaner codebase.
Came to say the same... also, if I see anything else called "Unity" in software, like ever, I'll just go on an insane unidirectional killing spree (not really, but it's irritating to say the least).
I had expected a blog series on SOLID principles applied to JS.
Interesting... wondering how many breaking changes there are, and if it would be possible to shim a few of them, and just make this "npm@4" somewhere in node@7 before the branch to node@8 starts.
I really hope that the final result will be some of the effects of yarn going into npm4 instead of a long term fragmentation here. I'm still looking at projects that are/have used bower, and that's enough to make things annoying, to say the least. At least Yarn seems to build on npm's conventions.
Not ES6, but with async/await, I tend to put this in the top of quite a few of my files, easier as a oneliner than pulling in from a library module a lot of the time.
const sleep = ms => new Promise(res => setTimeout(res, ms));
Said this earlier... I’ve pretty much rallied against any package manager that needs node+npm to install in the first place, it’s mostly redundant. In this case, it appears to work in line with the node_modules, package.json, and npm’s services, so I’m less disturbed by it… would prefer to see some push to get these changes aligned *in* npm@4/node@8, as there will be a lot of shifting for es6-style module support in that timeframe anyway.
I usually go a couple steps further, which is to fully copy the bootstrap.scss main file as well as variables.scss ... I'll update the bootstrap.scss copy to point to the local variables... I've done mixins in the past but never actually found myself changing existing ones. I'll include my own mixins that references the original. In this way, I have... /styles/root.scss includes bootstrap.scss /styles/bootstrap.scss references local vars and mixins, rest from bootstrap /styles/_variables.scss copy of bootstrap variables /styles/_mixins.scss reference bootstrap's mixins root is included at the top of the project... Other components will have a .scss next to the component that may include variables and/or mixins as needed. This way I can have my globals, and what I need inline. Beyond all of this, it's easier to comment out parts of bootstrap I'm not using. As to copying variables.scss, this is because I sometimes find it hard to remember what should/can be replaced. I also will usually adjust the font bases, as well as some of the colors and styling choices in variables directly. In the end it's a much cleaner codebase.again.. not sure why this is so hard to spread... const sleep = ms => new Promise(res => setTimeout(res, ms)); ... await sleep(10000);Not ES6, but with async/await, I tend to put this in the top of quite a few of my files, easier as a oneliner than pulling in from a library module a lot of the time. const sleep = ms => new Promise(res => setTimeout(res, ms));