Consider the following types in a schema:
type Foo {
id:ID!
weight:Number!
foo:Number!
}
type Bar {
usage: deidentify [Options] <infile> <outfile> | |
or deidentify [Options] <infile>... <outdir> | |
or deidentify [Options] <indir>... <outdir> | |
De-identify one or several DICOM files according the Basic Application | |
Level Confidentiality Profile specified in DICOM Part 15. | |
- | |
Options: | |
--expl-item-len encode sequence items with explicit length; at | |
default, non-empty sequence items are encoded with |
{ | |
alphanumeric_field_needs_quotes: false, | |
_leading_undderscores_ok: true, | |
trailing_underscores_ok_: true, | |
carriage_return_acts_like_comma: true | |
"vanilla JSON keys also supported": true | |
"a list with null element in at index 1": [0,,2,3,4,5] | |
"a list with null element in at index 0": [,1,2,3,4,5] | |
"a list with null final element": [0,1,2,3,4,] | |
"empty list is interpreted as the empty list, not [null]": [] |
"use strict"; | |
const _ = require("lodash"); | |
const defaultRules = require("@semantic-release/commit-analyzer/lib/default-release-rules"); | |
const scope = require(`${__dirname}/package.json`).name; // You may want to remove whatever's before a "/" in the name. | |
module.exports = _.map( | |
(defaultRules), | |
(defaultRule) => { | |
return { |
/* | |
Node itself is single-threaded. There is some concurrency stuff that comes from calling out to | |
C libraries and I/O, but it can be ignored unless you’re performance-tuning: in general, think of | |
your entire application as executing on one single thread. | |
Asynchronous actions in Node are all callback-based (“continuation passing style”, or CPS): at | |
any point when Node needs to perform something asynchronously (eg: I/O), the Node API will take | |
a callback and invokes that callback with the results. The convention for those callbacks is that | |
the first argument is the error (if any), and the rest of the arguments are the results. |
Consider the following types in a schema:
type Foo {
id:ID!
weight:Number!
foo:Number!
}
type Bar {
enum Variant<T> { | |
Foo(1), | |
Bar(true); | |
private final T data; | |
private Variant(T data) { | |
this.data = data; | |
} |
#!/bin/bash -u | |
# | |
# Run eslint on js and jsx files that are being committed, including doing a round of fixing up | |
# those files. | |
# | |
# Based on @dahjelle/pre-commit.sh and @jancimajek's one liner in that Gist. | |
# | |
NAMES=`git diff --diff-filter=d --cached --name-only -- '*.js' '*.jsx' | wc -l` |
/** | |
* Merges together Colors and BrandingImages into a single | |
* coherent branding structure. | |
* | |
* Using the function `brandingFromRedux` in `mapStateToProps` will give you | |
* a single object containing all the branding colors and images. If you return the | |
* object that we generate here (possibly with some other additions) as the `props` for | |
* your component, then you can use whatever you want from the branding colors and images | |
* without having to think about defaulting or wiring up additional fields or whatever. | |
* |
import React from 'react'; | |
import { View } from 'react-native'; | |
import { Scene, Router } from 'react-native-router-flux'; | |
import { connect } from 'react-redux'; | |
import _ from "lodash"; | |
import WelcomeBeeWell from './components/WelcomeBeeWell'; | |
import Login from './components/Login'; | |
import ForgotPassword from './components/ForgotPassword'; | |
import EmailSent from './components/EmailSent'; | |
import BrandWelcome from './components/BrandWelcome'; |
So, I was reading Why You shouldn’t use lodash anymore and use pure JavaScript instead, because once upon a time, I shifted from Underscore to Lodash, and I'm always on the lookout for the bestest JavaScript stdlib. At the same time, there was recently an interesting conversation on Twitter about how some of React's functionality can be easily implemented in modern vanilla JS. The code that came out of that was elegant and impressive, and so I have taken that as a message to ask if we really need the framework.
Unfortunately, it didn't start out well. After copy-pasting the ~100 lines of code that Lodash executes to perform a find, there was then this shocking claim: .