-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[theme] Warn when palette structure is wrong #20253
[theme] Warn when palette structure is wrong #20253
Conversation
fe5a97f
to
8c6d8f2
Compare
8c6d8f2
to
6792548
Compare
@material-ui/core: parsed: +0.17% , gzip: +0.25% Details of bundle changes.Comparing: d12a999...6b4f52c Details of page changes
|
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.
Well I have my usual reservations. console errors are just too easily missed. Defaulting to a different value when the input is wrong is not a good developer experience IMO. It's way more obvious to throw than log and use a default value.
@eps1lon Ideally I would 1. throw an explicit error in dev, and have a strange exception in production. But in the past, you have raised concerns about this approach. This leaves me us with two options: 2. the current one, 3. an explicit error in dev and prod but it has bundle size implication. What would you recommend? |
That's fine. I'll check-out how to implement error codes for prod which should reduce the size implication to a minimum. Different error stack traces between dev and prod would make debugging a nightmare. |
In practice, I would imagine that the error in dev mode would prevent 99% of the cases to land in production. In the event to does land in production, I would imagine that the developer will try to reproduce the error locally, in which case he would see an error. Well, I get your point now. The developer would fix the error in dev but had no clue if he fixed the same one than in production, Eww. Ok, let's go with 3. I recall the error minification was done 4 years ago by an intern on the React team. Maybe we should estimate the potential win before looking into it? Which in any case, it should mean that we are clear to go. |
e218a9c
to
6b4f52c
Compare
I have looked at how React handles the error encoding/decoding, it looks relatively simple: |
I hope that the following changes will resolve https://stackoverflow.com/questions/56897838/getting-a-error-typeerror-color-charat-is-not-a-function-in-c-node-modul (2k views in 8 months).
Closes #16341