alekseykulikov

Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.

My 3 developers team has just developed React.js application with 7668 lines of CSS (and just 2 !important). During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.

Here are main principles we use to write CSS for modern (IE11+) browsers:

• SUIT CSS naming conventions + SUIT CSS design principles;
• PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
• Flexbox is awesome. No need for grid framework;
• Normalize.css, base styles and variables are solid foundation for all components;

joshdover

Idiomatic React Testing Patterns

Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.

Setup

I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a beforeEach. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern that gives great defaults for each test example but allows every example to override props when needed:

rauschma

Installing Babel

The following are a few important npm packages.

Core Babel and access to Babel:

• babel-core: the core compilation machinery and plugin infrastructure for Babel. You will rarely need to install this package, because other packages such as babel-cli have it as a dependency, meaning that it will be automatically installed when they are installed.

• babel-cli: a command line interface to Babel. It includes the following commands:

• babel-doctor detects common problems with your Babel installation.

thom4parisot

'use strict';

var pkg = require('./package.json');
var gulp = require('gulp');
var utils = require('gulp-util');
var source = require('vinyl-source-stream');

var isWatching = false;
var isProduction = process.env.NODE_ENV === 'production';

hdragomir

<script type="text/javascript">
    (function () {
      "use strict";
      // once cached, the css file is stored on the client forever unless
      // the URL below is changed. Any change will invalidate the cache
      var css_href = './index_files/web-fonts.css';
      // a simple event handler wrapper
      function on(el, ev, callback) {
        if (el.addEventListener) {
          el.addEventListener(ev, callback, false);

kylemanna

#!/bin/bash
#
# Wrapper script for dovecot-antispam without using temporary files
# Look mom, no temporary files!
#
# Security is provided by locking the vmail user (dovecot-imap/antispam)
# only run this script via the sudoers line.  The script checks arguments
# to stay safe.  Log everything to syslog and return intelligent codes.
#
# sudoers:

NateWr

<?php
/**
 * Integrate Imager.js with WordPress
 *
 * Imager.js is BBC's solution for serving responsive and retina images, without
 * the double payload issues that affect other solutions. For more information:
 *
 * https://github.com/BBC-News/Imager.js/
 *
 * This collection of functions modifies the output of WordPress's

borisschapira

(function () {
    var verb = prompt("Verbe à chercher sur LeConjugueur.com :", "");
    var openWindow = window.open("http://leconjugueur.lefigaro.fr/php5/index.php?verbe=" + verb);
})()

branneman

Better local require() paths for Node.js

Problem

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.

Possible solutions

sstephenson

#!/usr/bin/env bash
#
# Wraps curl with a custom-drawn progress bar. Use it just like curl:
#
#     $ curl-progress -O http://example.com/file.tar.gz
#     $ curl-progress http://example.com/file.tar.gz > file.tar.gz
#
# All arguments to the program are passed directly to curl. Define your
# custom progress bar in the `print_progress` function.
#