Skip to content

Latest commit

 

History

History
123 lines (75 loc) · 7.31 KB

troubleshooting.md

File metadata and controls

123 lines (75 loc) · 7.31 KB
Raw

Stripes troubleshooting

In the order we ran into them, here are some things that can go wrong when building or running Stripes, and some hints on how to fix them.

addComponentAsRefTo(...): Only a ReactOwner can have refs.

Under certain circumstances, Stripes will fail to run and the JavaScript console will report

Uncaught Error: addComponentAsRefTo(...): Only a ReactOwner can have refs. You might be adding a ref to a component that was not created inside a component's `render` method, or you have multiple copies of React loaded (details: https://fb.me/react-refs-must-have-owner).
    at invariant (bundle.js:1509)
    at Object.addComponentAsRefTo (bundle.js:116958)

As the error message helpfully suggests, this is caused by the system picking up multiple copies of the React library from the node_modules directories of multiple Stripes-related packages, such as stripes-core and ui-users.

The fix, ridiculously, is to manually remove all copies of React from every node_modules directory but one -- canonically, that of stripes-sample-platform. So:

find stripes-* ui-* -name react | grep -v '^stripes-sample-platform' | xargs rm -r

(More discussion in STRIPES-220.)

Warning: Invalid context storeSubscription of type Subscription ... expected instance of Subscription.

Sometimes, when loading a React component for the first time, the JavaScript console will display the rather incoherent message:

"Warning: Failed context type: Invalid context `storeSubscription` of type `Subscription` supplied to `Connect(Form(UserForm))`, expected instance of `Subscription`."

According to comments on Redux issue 534, this is caused by having two copies of react-redux running at once, most likely due to multiple packages requiring it. The simple fix is to remove the node_modules/react-redux directories from all Stripes packages except stripes-core.

Warning: Cannot update during an existing state transition

Under certain circumstances -- the details are not clear -- the following warning appears in the JavaScript console:

Warning: setState(...): Cannot update during an existing state transition (such as within `render` or another component's constructor). Render methods should be a pure function of props and state; constructor side-effects are an anti-pattern, but can be moved to `componentWillMount`.

See STRIPES-216 for details.

EACCES: permission denied, symlink '../../home/mike/git/work/stripes-core/stripes.js' -> '/usr/bin/stripes'

On some platforms (e.g. Ubuntu 16.04.2 LTS, using Yarn and Node installed from packages), yarn link will fail in the stripes-core directory, reporting:

error An unexpected error occurred: "EACCES: permission denied, symlink '../../home/mike/git/work/stripes-core/stripes.js' -> '/usr/bin/stripes'".

The problem here is that, depending on whether NPM and/or Yarn was installed using operating-system packages (apt-get or Debian or Ubuntu systems), third-party packages (such as those provided by Homebrew on a Mac), using NPM itself or by other means, it may end up with a different idea of where "global" installs should be. In some cases, its guess is OK; in others, it chooses somewhere where you don't have write permission. You can find out where Yarn thinks global binaries should go using the yarn global bin command.

The fix is to explicitly define where to do "global" installs. In the .npmrc file in your home directory, add a prefix setting, pointing to a directory that you own:

prefix=/home/mike/lib/npm

And ensure that this directory both exists and contains a bin subdirectory (initially empty).

It should then be possible to yarn link.

See STRIPES-218 for details.

Uncaught TypeError: Cannot read property 'reducersFor' of undefined

Under certain circumstances, Stripes will fail to run and the JavaScript console will report

Uncaught TypeError: Cannot read property 'reducersFor' of undefined (bundle.js:77392)
    at OkapiResource.RESTResource (bundle.js:77392)
    at new OkapiResource (bundle.js:119656)

(I am seeing bundle.js rather than proper file line numbers because I am presently unable to yarn link Stripes Core -- see above -- so I am getting the released Stripes Core that does not do line-number mapping.)

This is caused by having a stale v1.x of react-redux hanging around somewhere in one of the projects' node_modules directory. (We don't know why that gets used rather than the one in stripes-sample-platform's Node Modules, but it does.)

The fix is to re-run yarn install in the package that has the stale react-redux. If you're not sure which package that is, re-run it in all of them to be sure.

(More discussion in STRIPES-219.)

Editing some source files does not cause yarn start to rebuild

In general, if a Stripes development server is already running when you edit one of the source files of Stripes or any included module, the server will emit a message webpack building..., then shortly afterwards webpack built 2e44cab1ab6c516e60e7 in 1658ms. So it's not necessary to restart the development server every time you make a change (though in general you do need to refresh the browser).

But sometimes, editing certain source files will not make this happen, and a clumsy, time-consuming manual restart is necessary.

Internally, WebPack uses inotify to be informed when a source file has changed. Linux supports only a limited number of watches. Annoyingly, if WebPack exceeds this number, it doesn't inform the developer but just proceeds blindly.

You can increase the limit on the number of watches by writing to the special file /proc/sys/fs/inotify/max_user_watches. You will need to become root to do this:

$ cat /proc/sys/fs/inotify/max_user_watches
8192
$ sudo bash
[sudo] password for mike:
# echo 524288 > /proc/sys/fs/inotify/max_user_watches
# exit
$ cat /proc/sys/fs/inotify/max_user_watches
524288
$

Once the limit is high enough, you can restart the server (e.g. yarn start) and it will re-scan the source tree, so that it is subsequently able to recognise changes in any source file.