-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Browser support config #3609
Browser support config #3609
Conversation
import PromiseRejectionError from '@/lib/promise-rejection-error'; | ||
import { ErrorHandler } from './error-handler'; | ||
import template from './template.html'; | ||
|
||
if (!matchesUA(navigator.userAgent, { allowHigherVersions: true })) { | ||
// TODO: create "browser outdated" page and redirect to it | ||
console.log('Your browser is outdated', resolveUserAgent(navigator.userAgent)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the place (and method) to put the redirect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's the right place. And probably you don't need a page for redirect: create a component with message or whatever, and conditionally show it instead of <div ng-view>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then we're still running potentially unsupported js for that page, which might fail it.
If we early redirect to a static html page, we don't have to worry about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you detect UA on client-side - you always have a chance to run unsupported code. If you'll change app-view/template.html
to something like this - no change it will render header/footer/page:
<div ng-if="$ctrl.isBrowserSupported">
<!-- original template here -->
</div>
<div ng-if="!$ctrl.isBrowserSupported">
Error! Error!!!! Unsupported browser!!!!111
</div>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's important that app-view
component itself shouldn't use any unsupported features, as well as all code it uses via imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds easy and simple.
I'll do that and also add a cypress test to make sure it doesn't break.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kravets-levko does this make sense? (I'd rather it have it's own template)
export default function init(ngModule) {
ngModule.factory(
'$exceptionHandler',
() => function exceptionHandler(exception) {
handler.process(exception);
},
);
const isBrowserSupported = someCheck(...);
ngModule.component('appView', {
template: isBrowserSupported ? template : notSupportedTemplate,
controller: isBrowserSupported ? AppViewComponent : NotSupportedCtrl,
});
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ranbena Yes, it's probably even better 👍
I think the initial approach of redirect is the correct one. We should assume that an unsupported feature can break the whole bundle and cause the app not to load in which case we won’t show any message to the user.
To avoid possible issues we should do the detection in a separate file we will include in index.html. Actually we can avoid redirect and just render a message. But point is: it should not depend on the bigger code base or on any of it working.
…--
Arik Fraimovich
On Wed, Mar 20 2019 at 10:56 AM, < ***@***.*** > wrote:
***@***.**** commented on this pull request.
In client/app/components/app-view/index.js (
#3609 (comment) ) :
> import PromiseRejectionError from '@/lib/promise-rejection-error';
import { ErrorHandler } from './error-handler'; import template from
'./template.html'; +if (!matchesUA(navigator.userAgent, {
allowHigherVersions: true })) { + // TODO: create "browser outdated" page
and redirect to it + console.log('Your browser is outdated',
resolveUserAgent(navigator.userAgent));
@ranbena ( https://github.com/ranbena ) Yes, it's probably even better 👍
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub (
#3609 (comment) ) , or
mute the thread (
https://github.com/notifications/unsubscribe-auth/AAEXLANRBiAZUjJumhgKj-8WTgnDVwv-ks5vYfeggaJpZM4b9QQl
).
|
Best practice would be to determine and redirect in @routes.route(org_scoped_rule('/<path:path>'))
@routes.route(org_scoped_rule('/'))
@supported_browser_required <--
@login_required
def index(**kwargs):
return render_index() but that would require re-implementing But going with JS has a clear problem - it's not a standalone file, but a js module. Options:
None are perfect, my personal pref is #2 (although not my comfort zone). |
We should avoid depending on our Python server, as ultimately I want to decouple serving the frontend client from the backend server. We already do this decoupling with the preview builds, which are served 100% by Netlify. So we're left with 1 & 3, and I think option 3 is the most robust option. |
If we only use browser supported features, what does Babel transpile? |
It's a good question and I'd like to know as well. My understanding is that it does not polyfill all features and if a feature is polyfilled (either with dedicated babel plugin / npm package / own util) we need to be explicitly define it to be excluded from the linter. For instance, if we'd still be targeting IE we'd get a lint error on using |
What I want to doGenerate The planDefine an npm script
|
This is what webpack is for. Not sure about the overrides but we can have a dedicated configuration for it (maybe in a separate project?).
But I feel like we’re reinventing the wheel here. Is there some prior art on how this is done?
…--
Arik Fraimovich
On Thu, Mar 21 2019 at 8:17 AM, < ***@***.*** > wrote:
What I want to do
Generate browserslist-useragent.js file that suits old browsers to be
loaded in client/app/index.html.
The plan
Define an npm script unsupported:build which transpiles the browserslist-useragent
npm package with a dedicated babel config into a single file.
@arikfr ( https://github.com/arikfr )
* Does this make sense?
* Can babel cli transpile a node module with its dependencies? Or can
webpack be used to so that?
* How do you provide babel with a preset override? (e.g. targets: [ "ie": 8
] )
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#3609 (comment) ) , or
mute the thread (
https://github.com/notifications/unsubscribe-auth/AAEXLEfM_JgT52s9oyVnV6WZfUajfo6Nks5vYyP6gaJpZM4b9QQl
).
|
Tested the redirect method in IE10 and 11 but the rest later this week (with windows machine). |
onIE(); | ||
} | ||
</script> | ||
<!--[if IE]><script>onIE()</script><![endif]--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IE only for now, consider using https://github.com/browserslist/browserslist-useragent in the future.
@arikfr made html page static, no template. Lmk if this is what you meant. |
Damnit, another codeclimate eslint plugin problem.. |
Also, @arikfr I put the redirect script in |
|
} | ||
}, | ||
"//": "browserslist set to 'Async functions' compatibility", | ||
"browserslist": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using configuration like we had before (> 0.5%, last 2 versions, Firefox ESR, ie 11, not dead
) so we don't have to update this list everytime browser versions update? I mean not necessarily the same one, but along the lines of > 0.5%, last 2 versions
etc instead of hardcoded versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so we don't have to update this list every time browser versions update
Why would you need to? We should revisit this list when:
- There are lower browser versions we would like to support. Won't happen cause we've looked at the browser stats.
- As a performance optimization to lower
app.js
file size. That can be done periodically.
instead of hardcoded version
The advantage of hardcoded versions is that they allow to easily and reliably determine if a user's browser is supported or not. But if we define sth like "last 2 versions" you would have no clear cutoff point (cause under last 2 versions doesn't mean you can't use Redash).
👍 |
* Browser support config * Removed some offending code * Added unsupported html page and redirect for IE * Typo in regex * Made html page static * Added redirect script to multi_org * Moved static html page to client/app
What type of PR is this?
Fixes #3579
Description
Using browserslist to define which browser versions Redash supports.
List established from minimum "Async function" browser feature support (caniuse).
This list allows us to utilize some powerful tools (all adhering to list automatically):
Babel transpiler 🚯
-ms
for Edge browser).babelrc
.Eslint rule - error on unsupported browser feature usage 👮
Outdated browser detection
with browserslist-useragentonly IE for now🚦