profile
viewpoint
Rory O’Kane roryokane Jersey City, United States https://roryokane.com/

jlehmann/git-submod-enhancements 26

Enhancements for git usability when using submodules

kirstein/generator-node-cs 5

Yeoman generator for node-coffeescript with no excess bullshit

roryokane/build-it-break-it-fix-it-contest-fall-2014 2

My entry for the Build It Break It Fix It contest (https://www.builditbreakit.org/) in Fall 2014. Includes a write-up about how it works and what I learned.

roryokane/active_admin 1

The administration framework for Ruby on Rails applications.

roryokane/bigtuna 1

Continuous Integration software written on top of Ruby on Rails 3 and DelayedJob.

roryokane/adfilt 0

The place where I, DandelionSprout, store my web filter lists, including my Nordic adblock list. As simple as that, really.

roryokane/ADHN 0

Inline summaries on the HN front page

roryokane/advent-of-code-solutions 0

My solutions to the Advent of Code coding puzzles, in Clojure, Ruby, and other languages.

roryokane/athens 0

Open-Source Networked Thought

Pull request review commentyargs/yargs

feat: expose hideBin helper for CJS

 var argv = require('yargs') ### Using the non-singleton interface  To use yargs without running as a singleton, do:+ ```js const argv = require('yargs/yargs')(process.argv.slice(2)) ``` -This is especially useful when using yargs in a library, as library authors should not pollute the global state.+We recommend using this approach by default, as the singleton interface is

Eventually, all of the docs will use the non-singleton interface require('yargs/yargs'). Thus, it might be nice to clarify what the singleton interface is here, to make it clearer which part of the above code block is the singleton/non-singleton interface.

We recommend using this approach by default, as the singleton interface (`require('yargs')`) is
bcoe

comment created time in 7 hours

Pull request review commentyargs/yargs

feat: expose hideBin helper for CJS

 You can run Yargs without any configuration, and it will do its best to parse `process.argv`:  ```javascript-require('yargs').argv+require('yargs/yargs')(process.argv.slice(2)).argv ```  You can also pass in the arguments yourself:  ```javascript-require('yargs')([ '-x', '1', '-y', '2' ]).argv+require('yargs/yargs')([ '-x', '1', '-y', '2' ]).argv ```  or use `.parse()` to do the same thing:  ```javascript-require('yargs').parse([ '-x', '1', '-y', '2' ])+require('yargs/yargs')().parse([ '-x', '1', '-y', '2' ]) ```  Calling `.parse()` with no arguments is equivalent to calling `yargs.argv`:
Calling `.parse()` with no arguments is equivalent to calling `.argv`:

The current sentence implies yargs.parse() is equivalent to calling yargs.argv, but neither of those are a thing when yargs is require('yargs/yargs').

bcoe

comment created time in 8 hours

Pull request review commentyargs/yargs

feat: expose hideBin helper for CJS

 You can run Yargs without any configuration, and it will do its best to parse `process.argv`:  ```javascript-require('yargs').argv+require('yargs/yargs')(process.argv.slice(2)).argv ```  You can also pass in the arguments yourself:  ```javascript-require('yargs')([ '-x', '1', '-y', '2' ]).argv+require('yargs/yargs')([ '-x', '1', '-y', '2' ]).argv ```  or use `.parse()` to do the same thing:  ```javascript-require('yargs').parse([ '-x', '1', '-y', '2' ])+require('yargs/yargs')().parse([ '-x', '1', '-y', '2' ]) ```  Calling `.parse()` with no arguments is equivalent to calling `yargs.argv`:  ```javascript-require('yargs').parse()+require('yargs')(process.argv.slice(2)).parse()
require('yargs/yargs')(process.argv.slice(2)).parse()
bcoe

comment created time in 8 hours

Pull request review commentyargs/yargs

feat: expose hideBin helper for CJS

 You can run Yargs without any configuration, and it will do its best to parse `process.argv`:  ```javascript-require('yargs').argv+require('yargs/yargs')(process.argv.slice(2)).argv

The introduction to this first example as well as the following example should be changed. Currently, the introductions to these code examples say they show calling yargs without passing arguments and then with passing arguments. However, with yargs/yargs, arguments must always be passed, so there’s no such distinction.

First drafts of more appropriate introductions for examples 1 and 2:

You can run Yargs directly on the relevant part of process.argv:

Yargs accepts any array of options. It doesn’t have to be from process.argv:

The change in this PR is nonetheless better than leaving the docs as recommending require('yargs'), so I would be fine with merging this PR before this problem is fixed and then fixing it later.

bcoe

comment created time in 8 hours

Pull request review commentyargs/yargs

feat: expose hideBin helper for CJS

 Yargs helps you build interactive command line tools, by parsing arguments and g It gives you:  * commands and (grouped) options (`my-program.js serve --port=5000`).-* a dynamically generated help menu based on your arguments.+* a dynamically generated help menu based on your arguments: -> <img width="400" src="https://raw.githubusercontent.com/yargs/yargs/master/screen.png">+```bash

I think the bash syntax highlighting is less readable than no syntax highlighting, due to its random-seeming coloring of & and return in the help text.

```

Also, this was a problem in the previous version too, but I notice this whole code block should be indented with two spaces so it counts as being within the bullet point, rather than outside of the bulleted list. So ultimately this section of the README should be written like this:

* a dynamically generated help menu based on your arguments:

  ```
  mocha [spec..]
  
  Run tests with Mocha
  
  Commands
    mocha inspect [spec..]  Run tests with Mocha                         [default]
    mocha init <path>       create a client-side Mocha setup at <path>
  
  Rules & Behavior
    --allow-uncaught           Allow uncaught errors to propagate        [boolean]
    --async-only, -A           Require all tests to use a callback (async) or
                               return a Promise                          [boolean]
  ```

* bash-completion shortcuts for commands and options.
bcoe

comment created time in 8 hours

Pull request review commentyargs/yargs

feat: expose hideBin helper for CJS

 starts with two extra elements:`process.execPath` and the path to the JavaScript file being executed. So if you’re getting your arguments from `process.argv` in Node, pass `process.argv.slice(2)` to Yargs. +_Note: yargs exposes the helper `hideBin`, handles the `process.argv.slice+logic for you._

There are a few formatting and grammar problems in this paragraph. Also, I personally think the text looks more readable if only the “Note” part of the paragraph is italic (as the majority of notes in api.md are formatted). Here is my suggested replacement paragraph that makes all those changes:

_**Note:**_ Yargs exposes the helper `hideBin`, which handles the `process.argv.slice`
logic for you.

Note: Yargs exposes the helper hideBin, which handles the process.argv.slice logic for you.

For comparison, here’s how it looks with all of my changes except making the paragraph non-italic:

Note: Yargs exposes the helper hideBin, which handles the process.argv.slice logic for you.

bcoe

comment created time in 8 hours

PullRequestReviewEvent
PullRequestReviewEvent

create barnchroryokane/spacemacs

branch : osx-fix-configuration-sample-code

created branch time in 9 days

PR opened syl20bnr/spacemacs

[osx] Fix broken code in instructions for setting config variables

Fix these problems:

  • unbalanced parens
  • misspelled name of function setq-default
+2 -2

0 comment

1 changed file

pr created time in 9 days

issue commentfacebook/react

Proposition about onInput/onChange

@rachelnabors

Unfortunately, a global configuration option would force every third party component author to be compatible with both modes

I think you overlooked a large part of the demo I provided. I was not suggesting a global configuration option—that was only @mr21’s idea. In my demo, I suggested adding a new attribute to React input elements, onChangeCompleted. Such an addition would be backwards-compatible because currently that attribute is ignored (and logs a warning that it is unknown).

There have been previous discussions, and if you have feedback, we'd love for you to join the conversation!

Discussing how to listen to input change events with React is a bit confusing because there have been multiple solutions discussed in multiple places:

  • #14857 (closed) suggested the same thing I want to suggest, adding a new attribute such as onChangeCompleted. That issue was automatically closed due to inactivity.
  • #19150 (open) (this issue) suggested a global configuration option $$useRealOnChange.
    • I then suggested an alternative, adding a new attribute such as onChangeCompleted.
  • #9657 (open) suggested a backwards-incompatible change to the existing attribute onChange.
    • Later comments in that issue discuss the idea of a new attribute such as onEveryChange, but the new attribute would be in addition to the backwards-incompatible change to onChange.

In which places would you like me to discuss my preferred solution of adding a backwards-compatible new attribute such as onChangeCompleted? You suggested #9657, but I’m thinking it would make the conversation clearer if you reopened issue #14857, or if I created a new issue and posted links to it in the other issues.

mr21

comment created time in 9 days

issue commentfacebook/react

Proposition about onInput/onChange

@rachelnabors Here’s an example I made that demonstrates the desired behavior, React not providing access to that behavior, and the way I personally wish React would give us access to that behavior:

CodeSandbox demo requesting native onchange in React

Mirror of that demo page

As CodeSandbox is a third-party site I am unfamiliar with, I don’t trust it to stay up forever, so here’s a mirror of the important parts of that demo page:

public/index.html

<div>
  <script>
    function handleNativeOnChange(event) {
      console.log("native change event fired", event.value);
    }
  </script>
  <h2>Demo of native <code>onchange</code> attribute</h2>
  <input type="number" onchange="handleNativeOnChange(this)" />
</div>

Demo of native onchange attribute

The above number-type input element logs a message when its change event is fired. Such an event is fired when a change is committed. The exact conditions of the event firing depend on the type of input element and possibly the browser, but in my testing with this particular input element, the change event seems to fire when any of the following happen:

  • The field is blurred after its value was changed.
  • The user presses Enter/Return on the keyboard after changing its value.
  • The user increments or decrements the number in the field by pressing Up or Down on the keyboard.

src/App.js

export default function App() {
  function handleOnChange(event) {
    console.log("React change event handler called", event.target.value);
  }

  return (
    <div className="App">
      <h2>
        Demo of React <code>onChange</code> attribute
      </h2>
      <input type="number" onChange={handleOnChange} />
    </div>
  );
}

Demo of React onChange attribute

The above number input logs a message on every input event, rather than only on change events. This is because React’s onChange attribute works the same as an onInput attribute.

Requested feature for React

It’s too late to redefine React’s onChange attribute, but can we add a way to get the same behavior as HTML’s onchange attribute without manually handling all the cases listed in that section?

Multiple possible solutions are discussed in React issue #19150, but the idea I currently favor is supporting a new attribute onChangeCompleted on input elements. If such an attribute existed, the following commented-out input element would work the same as in the native demo:

<input type="number" onChangeCompleted={handleOnChange} />
mr21

comment created time in 10 days

push eventroryokane/Transcribe-xsc-file-converter

Rory O’Kane

commit sha c3411a5a5191e35a0212dd40e30b1433317865ac

Fix README typo: missing space in the “Running from source code” section

view details

push time in 13 days

push eventroryokane/Transcribe-xsc-file-converter

dependabot[bot]

commit sha 2c8b155244f51288e7c18e13d99ab7d0ee304cb2

Bump lodash from 4.17.15 to 4.17.19 Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.15...4.17.19) Signed-off-by: dependabot[bot] <support@github.com>

view details

Rory O’Kane

commit sha 1aad3d5a01d2cf492353a84bd35b318d34539bb0

Merge pull request #1 from roryokane/dependabot/npm_and_yarn/lodash-4.17.19 Bump lodash from 4.17.15 to 4.17.19

view details

push time in 13 days

PR merged roryokane/Transcribe-xsc-file-converter

Bump lodash from 4.17.15 to 4.17.19 dependencies

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

1 comment

1 changed file

dependabot[bot]

pr closed time in 13 days

pull request commentroryokane/Transcribe-xsc-file-converter

Bump lodash from 4.17.15 to 4.17.19

I manually ran the tests on this branch and they pass. The lodash version upgrade seems safe according to lodash’s changelog.

dependabot[bot]

comment created time in 13 days

issue commentroryokane/detectindent

Sets sw=1, ts=1 when file uses tabs

Thanks for the bug report. In a local branch, I added the file you linked as a test case, and can reproduce the problem.

Desired behavior

I think the desired behavior for :DetectIndent on this file is to not modify sw or ts in the local buffer. That way, you can configure your desired sw and ts for tab-only files by setting them in your vimrc (e.g. set tabstop=4).

The cause of the bug

To determine where the code is going wrong, I checked the output of :verbose DetectIndent for that file:

Using tabs to indent. leading_tab_count: 795, leading_space_count: 4, leading_spaces_gcd: 1, leading_space_dict: {'11': 2, '6': 2} Changes from the buffer’s initial settings: tabstop changed from 8 to 1, shiftwidth changed from 8 to 1, softtabstop changed from 0 to -1

That output shows that the file actually does not use only tabs for indentation. (I think DetectIndent already handles files with only tabbed indentation correctly, leaving sw and ts at their global values.) Rather, this plugin changes sw and ts because 4 of the 1,890 lines in this file are indented with spaces. An example of such a line:

	my $i;
	my @prefixes = find_unique_prefixes(@stuff) unless $opts->{LIST_ONLY};

      TOPLOOP: # <------
	while (1) {
		my $last_lf = 0;

The algorithm wrongly guesses that since two of the lines in the file start with 6 spaces, and two lines start with 11 spaces, the desired visual indent size should be the greatest common denominator of 6 and 11, which is 1.

How to fix the bug

I’m still thinking of the best heuristic for fixing this. In this particular file it seems the indentation of the four space-indented lines should be ignored because they are more properly thought of as using spaces for alignment, not spaces for indentation. But what’s the best heuristic for handling a mix of space-indented lines and tab-indented lines in general?

In files where 10% of lines are indented with spaces, the sizes of those indents currently affect the displayed tabstop size, but I think they shouldn’t. However, I think that space-indented lines that consist of 49% of indented lines still should affect the tabstop size. What should the cutoff be? There should probably also be a minimum absolute number of space-indented lines for space-indented lines to be taken into account.

HaleTom

comment created time in 14 days

issue commentqvacua/vimr

Display scroll bar in window

More reasons for scroll bars

I want to note that scroll bars are useful for more reasons than using the pointer to scroll through the document, the reason given in the first comment. Scroll bars also provide these advantages:

  • They provide visual feedback on where you are in a document. In this way it provides the same information as Vim’s percentage label (e.g. 35%), but in a more directly interpretable way.
  • They provide visual feedback on how long the current document is. This can help me recognize whether I am in the right file, and how hard I should flick the scroll wheel or trackpad to reach a certain position in the document.

How scroll bars should work

For an example of how a Vim/Neovim GUI can display scroll bars, see how MacVim does it:

example of scroll bar in MacVim - top of scrollable view example of scroll bar in MacVim - near bottom of scrollable view example of scroll bar in MacVim - bottom of scrollable view

When calculating the length of the document for the purposes of the scroll bar, MacVim includes the distance you can scroll below the last line as part of the document length. I think this is a good way of accounting for the ability to scroll below the last line.

mjedmonds

comment created time in a month

startedmirage/irmin

started time in a month

PR opened webrtc-for-the-curious/webrtc-for-the-curious

In the intro, make sentence easier to parse by formatting book title

Before this, the sentence could be interpreted as “WebRTC, if you are curious, is an open source book…” and the reader would object “no, it’s a protocol.”

+1 -1

0 comment

1 changed file

pr created time in a month

push eventroryokane/webrtc-for-the-curious

Rory O’Kane

commit sha 0415f89a4a599f66f4bb15deb899cbd9b273815a

In the intro, make sentence easier to parse by formatting book title Before this, the sentence could be interpreted as “WebRTC, if you are curious, is an open source book…” and the reader would object “no, it’s a protocol.”

view details

push time in a month

startedMachineGunnur/GOG-Games

started time in a month

PR closed jenv/jenv

Fix wrong paths in Fish install instructions

Wrong extension for the fish config file and wrong name for the functions folder in the fish config that fish automatically loads. Also, at least on my Mac OS X 10.9 machine, the folder is ~/.config/, not ~/.conf.

+4 -4

3 comments

1 changed file

roryokane

pr closed time in a month

pull request commentjenv/jenv

Fix wrong paths in Fish install instructions

I ported all the changes from this PR that are still applicable into PR #307.

roryokane

comment created time in a month

PR opened jenv/jenv

Fix wrong paths in Fish install instructions

source of the information that it should be functions and not function: https://fishshell.com/docs/current/index.html#autoloading-functions

+2 -2

0 comment

1 changed file

pr created time in a month

push eventroryokane/jenv

Rory O’Kane

commit sha 64d418ccdc04d4b2580aded7ff5ce2070ef11273

Fix wrong paths in Fish install instructions source of the information that it should be `functions` and not `function`: https://fishshell.com/docs/current/index.html#autoloading-functions

view details

push time in a month

startedniw/HapticKey

started time in 2 months

issue openedtimburgan/timburgan

chess|move|e6h6|2599

Just push 'Submit new issue'. You don't need to do anything else.

created time in 2 months

issue openedtimburgan/timburgan

chess|move|h6h5|2599

Just push 'Submit new issue'. You don't need to do anything else.

created time in 2 months

issue openedtimburgan/timburgan

chess|move|c4e6|2599

Just push 'Submit new issue'. You don't need to do anything else.

created time in 2 months

startedevdenis/adb_root

started time in 2 months

PR opened danburzo/nbf

Use “...” consistently in the README’s example
+2 -2

0 comment

1 changed file

pr created time in 2 months

push eventroryokane/nbf

Rory O’Kane

commit sha f143d7aabcbb6f0434acd2ab80d84a7dba9c4049

Use “...” consistently in the README’s example

view details

push time in 2 months

fork roryokane/nbf

CLI tool for working with the Netscape Bookmark File format

fork in 2 months

PR opened danburzo/qsx

In README, fix terminology of “{}” characters

Parentheses are usually understood to be “()”. See https://en.wikipedia.org/wiki/Bracket#Parentheses and https://en.wikipedia.org/wiki/Bracket#Curly_brackets.

+2 -2

0 comment

1 changed file

pr created time in 2 months

push eventroryokane/qsx

Rory O’Kane

commit sha e72b60a698f1c28caebed4a9e9ac76cd08c36056

In README, fix terminology of “{}” characters Parentheses are usually understood to be “()”. See https://en.wikipedia.org/wiki/Bracket#Parentheses and https://en.wikipedia.org/wiki/Bracket#Curly_brackets.

view details

push time in 2 months

fork roryokane/qsx

Extended CSS selectors for querying the DOM

fork in 2 months

pull request commentathensresearch/athens

(experimental) fix(parser): performance fix for parser using LL(1)-like parsing

@HaojiXu I don’t understand exactly what problem you were running into with the Unicode character classes in the hashtag parsing regexp, but I wondered if it was related to browser support for that feature:

From those tables it seems that \p{…} in regexps is supported in all modern browsers as well as Node since v10. However, Firefox only gained this support in the last month with the release of version 78. Were you testing on Firefox 77? If so, that could be the problem.

HaojiXu

comment created time in 2 months

startedchocolateboy/google-direct

started time in 2 months

issue commentathensresearch/athens

Figure out why loading big pages is so slow

It makes sense that any-char would be slow, so that’s probably a good guess.

The parse rule introduced in commit 9433e79 demonstrates a more efficient way to parse “any chars”:

<any-non-page-link-chars> = #'[^\\[\\]]*'

We can probably replace other uses of any-chars with similar constructions.

I didn’t write the parser with regexes like that to start with because such regexes slightly increase the difficulty of adding new syntax that may be nested. For example, if page links could contain **bold** text, the above regex would have to be #'([^*\\[\\]]|\\*[^*])*' (or you could use a shorter regex paired with another parse rule). The information that the syntax for bold text is ** would be duplicated both in the bold rule and in regexes of rules that can contain bold text.

tangjeff0

comment created time in 2 months

PR closed you-dont-need/You-Dont-Need-Lodash-Underscore

Correct the description of _.isString

The previous description was copy-pasted from _.endsWith. This updated description comes from https://lodash.com/docs/4.17.15#isString.

+1 -1

2 comments

1 changed file

roryokane

pr closed time in 2 months

pull request commentyou-dont-need/You-Dont-Need-Lodash-Underscore

Correct the description of _.isString

I notice that you already merged a PR that incorporates this PR’s changes and also does the extra things you were asking me to do: PR #288. That means there is no need for my PR, so I will close it.

roryokane

comment created time in 2 months

startedparnold-x/nasc

started time in 2 months

push eventroryokane/CalcuDoc

Rory O’Kane

commit sha 8990f427052918073ddcde39a94efc724b8b7c90

Update README image link so it renders on GitHub It rendered on GitHub before, but GitHub changed their Markdown rendering engine.

view details

push time in 3 months

issue openedfacebook/flow

Can’t assign values to `mixed` when it’s within an Array or Object type

Flow version: v0.128.0

Expected behavior

According to the documentation page Mixed Types, anything can be assigned to mixed:

mixed will accept any type of value. Strings, numbers, objects, functions– anything will work.

That documentation page doesn’t say it should work any different when mixed is inside an array or object. Therefore, the following code, which uses an Array<mixed> type, should pass Flow type checking:

const arrayOfNumbers: Array<number> = [1, 2, 3];
const arrayOfMixed: Array<mixed> = arrayOfNumbers;

Additionally, all of the example code in the “Actual behavior” section should pass Flow type checking.

I know that covariance and contravariance can sometimes cause similar confusion, but I don’t see why it would change my expectations here.

Actual behavior

Flow raises type errors in four of the six paragraphs of code below (demo on Try Flow):

// @flow

// mixed works when it’s a top-level value
const num: number = 3;
const mix: mixed = num;

// mixed FAILS inside array types
const arrayOfNumbers: Array<number> = [1, 2, 3];
const arrayOfMixed: Array<mixed> = arrayOfNumbers;

// mixed FAILS inside object types
const personWithNumberAge: { age: number } = { age: 55 };
const personWithMixedAge: { age: mixed } = personWithNumberAge;

// mixed FAILS inside indexed object types
const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
const stringsToMixed: { [string]: mixed } = stringsToNumbers;

// mixed FAILS inside indexed object types as function parameters (my use-case)
function withStringsToMixed(obj: { [string]: mixed }): Array<string> {
  return Object.keys(obj);
}
withStringsToMixed(stringsToNumbers);

// generics work inside indexed object types
function withStringsToGeneric<T>(obj: { [string]: T }): Array<string> {
  return Object.keys(obj);
}
withStringsToGeneric(stringsToNumbers);

The type errors are of this form:

Cannot assign somethingContainingNumbers to somethingContainingMixed because number [1] is incompatible with mixed [2] in [some container]. [incompatible-type]

    9: const arrayOfMixed: Array<mixed> = arrayOfNumbers;
                                          ^ Cannot assign `arrayOfNumbers` to `arrayOfMixed` because number [1] is incompatible with mixed [2] in array element. [incompatible-type]
        References:
        8: const arrayOfNumbers: Array<number> = [1, 2, 3];
                                       ^ [1]
        9: const arrayOfMixed: Array<mixed> = arrayOfNumbers;
                                     ^ [2]
    13: const personWithMixedAge: { age: mixed } = personWithNumberAge;
                                                   ^ Cannot assign `personWithNumberAge` to `personWithMixedAge` because number [1] is incompatible with mixed [2] in property `age`. [incompatible-type]
        References:
        12: const personWithNumberAge: { age: number } = { age: 55 };
                                              ^ [1]
        13: const personWithMixedAge: { age: mixed } = personWithNumberAge;
                                             ^ [2]
    17: const stringsToMixed: { [string]: mixed } = stringsToNumbers;
                                                    ^ Cannot assign `stringsToNumbers` to `stringsToMixed` because number [1] is incompatible with mixed [2] in the indexer property. [incompatible-type]
        References:
        16: const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
                                                ^ [1]
        17: const stringsToMixed: { [string]: mixed } = stringsToNumbers;
                                              ^ [2]
    23: withStringsToMixed(stringsToNumbers);
                           ^ Cannot call `withStringsToMixed` with `stringsToNumbers` bound to `obj` because number [1] is incompatible with mixed [2] in the indexer property. [incompatible-call]
        References:
        16: const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
                                                ^ [1]
        20: function withStringsToMixed(obj: { [string]: mixed }): Array<string> {
                                                         ^ [2]

As the last paragraph “generics work inside indexed object types” shows, this issue can be worked around by adding an unused generic parameter to the function. This workaround is only possible if the mixed-containing type is a parameter to the function, not if it’s a local variable.

For comparison, when I try writing equivalent code in TypeScript by changing mixed to unknown, TypeScript raises no errors. I know that Flow and TypeScript are not always directly comparable, though, since their type systems differ in a few ways.

created time in 3 months

PR opened microsoft/TypeScript-Handbook

Document `unknown` in Basic Types

Right now, the unknown top-level type is only documented in the release notes: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type

It’s good to document unknown next to the any type, because it replaces certain use-cases for any. This new documentation gives an overview of unknown and focuses on giving practical examples, while the existing release notes focus on defining the new feature and give exhaustive examples.

Fixes #960

+51 -6

0 comment

1 changed file

pr created time in 3 months

create barnchroryokane/TypeScript-Handbook

branch : document-unknown-type

created branch time in 3 months

fork roryokane/TypeScript-Handbook

The TypeScript Handbook is a comprehensive guide to the TypeScript language

fork in 3 months

issue commentjorgebucaran/hyperapp

Lorem ipsum in your website

Specifically, the pages that contain nothing but placeholder text are hyperapp.dev/guides (edit guides.md) and hyperapp.dev/ecosystem (edit ecosystem.md).

iamanas20

comment created time in 3 months

PR opened jorgebucaran/hyperapp

Fix spelling of “whether” in tutorial

affects https://hyperapp.dev/tutorial

+4 -4

0 comment

1 changed file

pr created time in 3 months

push eventroryokane/hyperapp

Rory O’Kane

commit sha 6cb99b7a806ab9d69599c8ef4b17467a2cc435c3

Fix spelling of “whether” in tutorial

view details

push time in 3 months

fork roryokane/hyperapp

The tiny framework for building hypertext applications.

https://hyperapp.dev

fork in 3 months

PR opened you-dont-need/You-Dont-Need-Lodash-Underscore

Correct the description of _.isString

The previous description was copy-pasted from _.endsWith. This updated description comes from https://lodash.com/docs/4.17.15#isString.

+1 -1

0 comment

1 changed file

pr created time in 3 months

push eventroryokane/You-Dont-Need-Lodash-Underscore

Rory O’Kane

commit sha 1f1bb0b567db383f31b69d99d0eacdfccab8d3a4

Correct the description of _.isString The previous description was copy-pasted from _.endsWith. This updated description comes from https://lodash.com/docs/4.17.15#isString.

view details

push time in 3 months

fork roryokane/You-Dont-Need-Lodash-Underscore

List of JavaScript methods which you can use natively + ESLint Plugin

fork in 3 months

issue commentlobsters/lobsters

Refactoring: rename Comment scope `for_user` to `accessible_to_user`

I’m not working on this, so feel free.

roryokane

comment created time in 3 months

issue commentfacebook/react

Proposition about onInput/onChange

If I understand your proposed solution correctly, React.$$useRealOnChange would be a global variable that would change the behavior of onChange in code such as <input onChange={event => handleChange(event)} />. The goal is to easily listen to the browser’s built-in change event.

I, too, wish that React allowed me to listen to the native change event. However, I have concerns about that specific solution. I worry that adding a global variable like React.$$useRealOnChange would cause surprising bugs and complicate testing. If you set React.$$useRealOnChange to true in one part of the code, it could affects parts of the code that were written assuming a value of false for it.

I favor the solution proposed by this older issue: #14857 “Easily handle browser 'change' events”. That issue proposed supporting a new attribute on input elements that act like a browser-native onchange attribute. It suggested these names as possibilities:

  • onChangeAndBlur
  • onChangeNative
  • onChangeCompleted
  • onCompleteChange

That issue was automatically closed for being “stale”, so perhaps this issue should become the new active issue about accessing the browser-native onchange.

mr21

comment created time in 3 months

more