49d343941e
* ci: test docs-publish * Specify to use prod * Babel should transpile with env set by webpack * in-progress * in-progress * Polyfill for ie11 and edge features * Ditch polyfills w/ babel - we'll use a service for now * Bump tools version; shift vtk.js up a layer * Specify we shouldn't target older than IE 11 * ditch babel plugins that should be covered by preset-env * Add a top level build demo command * Let our babel config determine settings * Same babel fixes as PWA * Rebuild deps that don't satisfy our target * Mini helper script for excluding all node_modules, except... * Shift vtk.js dep up a layer * Kill core-js * Export in a node happy way * Updated yarn lock * Set NODE_ENV when launching anything w/ WebPack * docs: updated FAQ * docs: on browser support * Add support for redux browser extension * misc. small clean-up * docs: Remove roadmap page; add browser-support to sidebar * Formatting * Remove roadmap links * Formatting * ci: Remove config syntax error * Simplified bug report template * update community request template * Update question's template * simplify build scripts * specify new script names * fix: for measurement api being pruned by minimizer in prod builds * Use named exports * Simplify config * Let's not do so much heavy lifting for a dev-server build * fix dev build * Add hotkeys to demo * fix: jest babel config and env specific configs * Remove call to non-existant command * Shift experimental proposal plugin up a layer * Use `https` * Try with reduced number of package exceptions * Try to resolve cypress issue * Try to fix cypress issue in CI * Skip https
48 lines
1.7 KiB
Markdown
48 lines
1.7 KiB
Markdown
# Browser Support
|
|
|
|
The browsers that we support are specified in the `.browserlistrc` file located
|
|
in the `platform/viewer` project. While we leverage the latest language features
|
|
when writing code, we rely on `babel` to _transpile_ our code so that it can run
|
|
in the browsers that we support.
|
|
|
|
## In Practice
|
|
|
|
The OHIF Viewer is capable of _running_ on:
|
|
|
|
- IE 11
|
|
- FireFox
|
|
- Chrome
|
|
- Safari
|
|
- Edge
|
|
|
|
However, we do not have the resources to adequately test and maintain bug free
|
|
functionality across all of these. In order to push web based medical imaging
|
|
forward, we focus our development efforts on recent version of modern evergreen
|
|
browsers.
|
|
|
|
Our support of older browsers equates to our willingness to review PRs for bug
|
|
fixes, and target their minimum JS support whenever possible.
|
|
|
|
### Polyfills
|
|
|
|
> A polyfill, or polyfiller, is a piece of code (or plugin) that provides the
|
|
> technology that you, the developer, expect the browser to provide natively.
|
|
|
|
An example of a polyfill is that you expect `Array.prototype.filter` to exist,
|
|
but for some reason, the browser that's being used has not implemented that
|
|
language feature yet. Our earlier transpilation will rectify _syntax_
|
|
discrepencies, but unimplemented features require a "temporary" implementation.
|
|
That's where polyfills step in.
|
|
|
|
You can utilize a service like [polyfill.io](https://polyfill.io/v3/) to
|
|
auto-detect and apply polyfills as needed, or you can update the PWA build to
|
|
include polyfill's in your bundle by incorporating [core-js][core-js]
|
|
|
|
<!--
|
|
Links
|
|
-->
|
|
|
|
<!-- prettier-ignore-start -->
|
|
[core-js]: https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md
|
|
<!-- prettier-ignore-end -->
|