emilio-martinez / is-datatype Goto Github PK

Currently, the schema is passed as a third parameter for is:

is([value], [DataType], [options]);

Challenges

The options are too freeform and hard to express.

• They're somehow tied to the DataType, yet separate.
• Options slot encompasses shared options, which can be confusing.

Schema is mixed into options, which adds to the confusion.

• Has both props and items.
• Having the schema as a nested option adds complexity and confusion.
• Schema can be used to describe types other than object—more complexity and confusion.

Transition thoughts

// Tie the options closer to the DataType itself.
// This would more clearly tie options to the type they actually belong to.
is(val, DataType.string({ type_specific_options }));

// For schemas
// Shape would check of obe
is(val, DataType.withShape({
  name: DataType.string().required,
  age: DataType.number({ min: 0 }).required,
  address: DataType.withShape(...)
}));

// For multiple DataTypes
is(val, DataType.oneOf(DataType.string, DataType.number));

For String

// Current is
is(val, DataType.string, {
  pattern: string,
  patternFlags: string,
  exclEmpty: boolean
});

// Transition
// patternFlags would be removed. A regular expression would be used instead.
is(val, DataType.string({ pattern: regexp, empty: boolean }));

For Number

// Current is
is(val, DataType.number, {
  multipleOf: number,
  min: number,
  max: number,
  exclMin: number,
  exclMax: number
});

// Transition
// Would likely drop exclMin and exclMax. They're too close to min and max.
is(val, DataType.number());
is(val, DataType.number({ min: number, max: number, multiple: number }));
is(val, DataType.integer());
is(val, DataType.natural());

For Array

// Current is
is(val, DataType.array, { type: DataType | DataType[],
                          min: number,
                          max: number,
                          exclMin: number,
                          exclMax: number,
                          schema: isTypeSchema | isTypeSchema[] | null })

// Transition
// Would likely drop exclMin and exclMax. They're too close to min and max.
// DataType array in `type` would be replaced by oneOf
// `schema` would be replaced by `withShape`
is(val, DataType.array({ of: DataType, min: number, max: number }))
is(val, DataType.array({ of: DataType.oneOf(DataType.string, DataType.number) }))
is(val, DataType.array({ of: DataType.withShape(...) }))

For Object

// Current is
is(val, DataType.object, { arrayAsObject: boolean,
                           schema: isTypeSchema | isTypeSchema[] | null })

// Transition
// `arrayAsObject` would be replaced by `oneOf`
is(val, DataType.object())
is(val, DataType.withShape(...))
is(val, DataType.oneOf(DataType.object(), DataType.array()))

Wouldn't change

is(val, DataType.function());
is(val, DataType.boolean());
is(val, DataType.undefined());
is(val, DataType.null());
is(val, DataType.any());

Further departures?

Haven't put much thought into the following. Mostly jotting down ideas.

Shorten DataType to just Type?

It would just reduce noise a little bit.

// General pattern
is(val, Type.type({ type_specific_options }));

// Applied
is(val, Type.function());
is(val, Type.boolean());
is(val, Type.undefined());
is(val, Type.null());
is(val, Type.any());
is(val, Type.object()))
is(val, Type.array());
is(val, Type.number());
is(val, Type.string());
is(val, Type.oneOf(Type.object(), Type.array()));
is(val, Type.withShape(...));

Append is?

The readability of "is [value] DataType" would not make sense anymore: "DataType is [value]".
An alternative word could be found for is, such as check, test, matches, or something like that.

// General pattern
DataType.type({ type_specific_options }).check(val);

// Applied
DataType.function().check(val);
DataType.boolean().check(val);
DataType.undefined().check(val);
DataType.null().check(val);
DataType.any().check(val);
DataType.object().check(val)
DataType.array().check(val);
DataType.number().check(val);
DataType.string().check(val);
DataType.oneOf(DataType.object(), DataType.array()).check(val)
DataType.withShape(...).check(val)

The addition of symbol in ES2015 adds a new primitive to the extent that:

typeof Symbol() === 'symbol'
typeof Symbol('foo') === 'symbol'
typeof Symbol.iterator === 'symbol'

Read more about Symbol.

The goal of this library is to provide typeof functionality, so detecting this in is is-datatype is fairly important to the extent that it is reasonably possible. To elaborate on that, there needs to be a careful determination on what are the parameters to provide an accurate detection of symbol given that a lot of applications are run in environments that don't support it natively and therefore symbol is either unavailable or polyfilled. The latter scenario is where careful attention is required; a fairly reliable common denominator needs to be found for detection since in some circumstances the implementation may be buggy or done with caveats, i.e., there is no true substitute to the real implementation.

• Research coverage of native availability.

• Research most-widely used polyfills and their caveats

• Document any edge cases and caveats found.

• Write test cases on diverse environments, if found applicable

  • without Symbol support, e.g., shouldn't break
  • using the most-popular polyfills isolated from each other and in scenarios where they might place Symbol in different scopes, e.g., import { Symbol } from 'symbol-polyfill', import 'symbol-polyfill', or window.Symbol.
  • with native Symbol support

Resources

• Symbol specification

• Symbol in MDN

• ES6 In Depth: Symbols

• core-js implementation of Symbol and caveats

• polyfill.io features

  • Their polyfill source
  • Their Symbol test cases page and source

• Polyfill at medikoo/es6-symbol. Comes up pretty high up in Google.

• Bringing Symbols to ES5

• Generate yarn.lock

• Add build task to test-ci

• Ensure consistency between output on Travis and local

Should is-datatype detect Promise as a function use case? I don't know if it's a common enough use case but it comes to mind as a simple use case that could probably easily be fulfilled; however, it may just add bloat and not be worth it.

Below are a few test cases that might prove helpful in the endeavor: http://codepen.io/emilio-martinez/pen/MpQaLB/. Most importantly, the check should not break when Promise is unavailable or implemented in a faulty manner; see browser support.

On isValidOptions, if null is passed as the options object, a TypeError will occur:

TypeError: Cannot convert undefined or null to object

• Ensure a valid object is passed to Object.keys()
• Write test cases for passing rogue objects in the options param

Options exclMin and exclMax add complexity to the options; however, their functionality easily be achieved by min and max.

Related #132

This avoids issues such as, for example, if the working directory is not clean, np will botch the release process.

• Check that there is a user logged in
• Check that the working directory is clean

• Don't validate options upfront. Only validate options as they are needed or slightly before, as appropriate.
• Check for primitives first. Those are perhaps are the faster checks overall. (Related #35)
• Use benchmarks to drive decisions. For the time being, the tests will only be in isolation; integrated tests will come later.
• Drive towards a smaller gzipped size. Ultimately, the size that may arguably count the most is the compressed size. Certain benefits may come from repetition, for example, so it's important to test against that.

Version 2.6.0 of jasmine-core just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As jasmine-core is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

The following use cases are confusing, and while uncommon, there needs to be an approach towards these decided as documented:

typeof new Boolean(true) === 'object'; 
typeof new Number(1) === 'object'; 
typeof new String('abc') === 'object';

• Write test cases
• Write documentation and reasoning behind approach

The idea is:

is('pizza', DataType.primitive) // true
is(10, DataType.primitive) // true
is(false, DataType.primitive) // true
is(true, DataType.primitive) // true
is({}, DataType.primitive) // false
is([], DataType.primitive) // false
is(() => {}, DataType.primitive) // false