Component Library package & Component Catalog app code
Go to file
Michael Hadley b907c12d7a Prevent text area with auto resize from jumping scroll position
The old logic looked like this:

```
if (this._textarea.scrollHeight > minHeight) {
  this._textarea.style.height = minHeight + 'px'
  this._textarea.style.height = this._textarea.scrollHeight + 'px'
}
```

Imagine a case where the `minHeight` is actually less than the current
height of the text area due to the current content. The height of the
element would be set to a smaller value, and then later reset to the
desired height. This causes the overall scroll height of the page to
shrink (because the text-area did), and then expand again. Now the
scroll position for the user on the page has changed, and this happens
on every keystroke.

This change just skips the first assignment to `.height`. I'm not sure why it
was initially there, but I can't see a reason for keeping it (especially
since it seems to be the cause of this bug).
2020-03-27 11:34:00 -07:00
docs Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
lib Prevent text area with auto resize from jumping scroll position 2020-03-27 11:34:00 -07:00
nix Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
script Allow deprecated pennant import for now 2020-03-17 13:43:24 -07:00
src Merge branch 'master' into tessa/update-premium-pennants 2020-03-23 12:03:04 -07:00
styleguide-app Cross-list clickable svg in button category and icon category 2020-03-23 17:49:37 -07:00
tests Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
.envrc.nix Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
.gitattributes Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
.gitignore Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
.npmignore Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
.travis.yml Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
elm.json Bump 2020-03-23 14:49:37 -07:00
LICENSE Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
Makefile Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
netlify.toml Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
package-lock.json Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
package.json Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
README.md Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00
shell.nix Revert "Merge pull request #461 from NoRedInk/puffins/prepare-for-merge" 2020-03-06 20:00:34 +01:00

noredink-ui

UI widgets we use.

Versioning policy

We try to avoid breaking changes and the associated major version bumps in this package. The reason for that is to avoid the following scenario:

  |
  x   4.6.0: Adding RadioButton widget
  |
  x   5.0.0: Breaking change in the TextArea widget
  |
  x   5.0.1: Styling fix in the Checkbox widget
  |

Suppose you just released version 5.0.1, a small styling fix in the checkbox widget, for a story you're working on. If the project you're working in currently pulls in noredink-ui at version 4.x, then getting to your styling fix means pulling in a new major version of noredink-ui. This breaks all TextArea widgets across the project, so those will need to be fixed before you can do anything else, potentially a big effort.

To prevent these big Yaks from suddenly showing up in seemingly trivial tasks we prefer to avoid breaking changes in the package. Instead when we need to make a breaking change in a widget, we create a new module for it Nri.Ui.MyWidget.VX. Similarly, when we build custom elements in JavaScript we create a file lib/MyWidget/VX.js and define a custom element nri-mywidget-vX.

We should change this process if we feel it's not working for us!

Moving Widgets to noredink-ui

If you are moving in a widget from the monolith:

  • Copy the contents of Nri.SomeModule and its tests to Nri.Ui.SomeModule.V1 in noredink-ui
  • Publish!
  • If you feel confident upgrading pre-existing usages of the widget, switch over to it everywhere!
  • If the new version introduces big changes and you'd rather keep the old one around for now, rename Nri.SomeModule to Nri.DEPRECATEDSomeModule in the monolith and start using Nri.Ui.SomeModule.V1 where you need it

Phasing out old versions

Our goal is to gradually move to the newest version of each widget, and remove the old versions when they are no longer used.

This means:

  • We should avoid introducing new references to old versions of a widget
  • When touching code that uses a widget, prefer upgrading to the latest version
  • If you introduce a new version of a widget, please consider taking the time to upgrade all previous usages
    • If for some reason this isn't feasible, create a story in your team's backlog so that you can prioritize it separately without disrupting your current work
  • You can delete an old version of a widget when there are no usages left
    • Currently, noredink-ui is used by the monolith, CCS and tutorials
    • Note: this will be a major version bump, so you may want to batch deletions together

Examples

This repo contains an app showcasing all of these UI widgets.

To see them locally:

script/develop.sh

If you'd like to test your widget in the monolith before publishing, run script/test-elm-package.py ../path_to_this_repo from the monolith's directory.

Tests

Run tests with

make test

CI (Travis)

Travis will run make ci to verify everything looks good. You can run this locally to catch errors before you push!

Deploying

Once your PR is merged, you can publish master as a new version:

Run the following to bump && publish the version in elm.json:

elm bump

Commit and push your changes in a PR. Once it's approved and merged, then:

git tag -a 5.10.0 -m "release version 5.10.0"
git push origin 5.10.0
elm publish

You can also add a tag in https://github.com/NoRedInk/noredink-ui/releases/new if you want to add more detail.

Once you've published, you should see the latest version at https://package.elm-lang.org/packages/NoRedInk/noredink-ui/.

Developing with Nix

You can develop this package without installing anything globally by using Nix. To get started, install nix from nixos.org/nix.

After that's set up in your shell (just follow the instructions at the end of the installation script) you can run nix-shell to get a development environment with everything you need.

If you find that inconvenient, try using direnv. Once that's set up, echo use nix > .envrc and then direnv allow. Anytime you enter the project your shell will automatically pick up the right dependencies.

If you find that direnv loads too slow, there are faster loading strategies than the default in their wiki.

Working with upstream dependencies

We use niv to manage Nix dependencies. It is automatically loaded in the Nix environment.

Here are some things you might need to do:

Task Command
Add a non-npm, non-Elm dependency packaged with Nix Look if it's in nixpkgs, or niv add github.com/user/repo
Update Nixpkgs niv update nixpkgs
See all our dependencies Look in shell.nix
See all our sources niv show