6 ms·

> In React 17, React automatically modifies the console methods like console.log() to silence the logs in the second call to lifecycle functions. However, it ma

by mbell 4y ago

> In React 17, React automatically modifies the console methods like console.log() to silence the logs in the second call to lifecycle functions. However, it may cause undesired behavior in certain cases where a workaround can be used. I feel like when you've gotten to the point that something like this has been proposed and accepted as a good solution to a problem your framework is facing, it may be a good time to stop and reconsider the approach of the framework.

btown 4y ago
This gets at something deeper: React has a policy of “in the dev environment anything goes; we will mess with your code and its runtime performance to help detect bugs or future bugs; you want us to do this, even if you think you don’t.” But this assumes good QA and staging environments exist and are used correctly. In reality, many users of React test on local and immediately deploy into production. The more the environments differ, the less friendly React is to these users. Timing issues and race conditions may surface in production. And thank goodness this isn’t Python where a log statement can consume an iterable if you allow it to do so! And for those saying “Strict Mode is opt-in” - your coworker may opt in your whole app without you knowing it. Hopefully you see the PR or the Slack thread. So much in React now enables this “spooky action at a distance.” The React team has put a lot of thought into balancing the performance needs of large codebases with the stability needs of smaller teams with less robust SDLC. I can’t think of a better workaround. But it’s still going to cause chaos in the wild.
- andrewingram 4y ago
  I agree with the sentiment of not being comfortable with dev and prod differents. That said, with React these dev mode differences are intentionally about making obscure production issues (such as timing ones) rear their ugly heads in development. The goal is that if your code works without issues in dev, it’ll work even better in production. It’s a thin line for sure, but I broadly support the way they’ve done it so far.
- kmlx 4y ago
  can be solved this way: - npm start when developing - deploy on dev using the artefacts from npm run build builds take a bit longer this way, but it guarantees QA will test using a non-dev build
  - KronisLV 4y ago
    > In reality, many users of React test on local and immediately deploy into production. > deploy on dev using the artefacts from npm run build These two statements do not fit together. I agree that "You should have dev/test/staging/... environments" is the correct answer, but clearly that's not the reality for everyone.
    - kmlx 4y ago
      > clearly that's not the reality for everyone might not be the reality, but multiple envs is the only correct answer.
kristaps 4y ago
I agree, at first reading this sounds just plain horrible. I haven't tried doing any research, can anyone point out why it's not?
mhoad 4y ago
Broadly speaking I think React is in a weird spot where they have painted themselves into a corner with no obvious way of fixing it by essentially forking the DOM and doing so many things independently of the wider web platform. That approach made a lot of sense when it was first released but is just a liability at this point. If you’re deep in React land and it’s all you know I think 2022 might be a good time to expand your horizons a bit because the landscape around you has changed a lot in the past five years.
- resoluteteeth 4y ago
  > Broadly speaking I think React is in a weird spot where they have painted themselves into a corner with no obvious way of fixing it by essentially forking the DOM and doing so many things independently of the wider web platform. That approach made a lot of sense when it was first released but is just a liability at this point. The problems that strict mode is addressing with this somewhat unusual approach have absolutely nothing to do with the VDOM. Rather it is that code using React is subject to restrictions (being pure functions and following the hook rules when using hooks) that are impossible to express or enforce at compile time in javascript.
  - mhoad 4y ago
    Sorry just to be clear, I wasn’t tying this to the strict mode situation but was attaching myself to the concept that this is just one of several points where the framework is showing some signs that it’s time to start thinking about alternatives particularly because I don’t think some of them are fixable at this point, they are just too central to the entire project and those decisions no longer make sense.
- joeyjojo 4y ago
  Outside of Vue, and maybe Angular, are there any other stable alternatives with a decent ecosystem? I'd love to hop off the React train, but I haven't found anything that compares to the experience of just using create-react-app with Typescript support.
  - 4y ago
nightski 4y ago
It's not a "solution". It's more akin to a lint rule imho. Javascript provides no language level guarantees. There is no static type checker or compiler to enforce these things. So we rely on linters, tests, and assertions. Yay dynamic languages.
danabramov 4y ago
Thank you for the feedback. I agree this behavior was confusing. (We changed it to slightly dimming the second log in response to the community discussion. This change is released in React 18.) The new behavior seems like the tradeoff we dislike the least but new ideas are always welcome. Overall, we’ve found that calling some methods twice is a crude but effective way to surface a class of bugs early. I absolutely agree that it’s not the best possible way to do that, and we’re always thinking about ways to surface that earlier — for example, at the compile time. But for now, the current solution is the best we have found in practice.
- tomduncalf 4y ago
  Thanks for clarifying Dan. I think it might be appropriate for React to console.warn that strict mode is active (in dev mode) with a short description of this side effect, or perhaps the “dimmed” log message could have an explanation after it. Not all users have explicitly enabled strict mode (e.g. in my case I just started a new Next.js project) so this behaviour can be quite surprising and hard to track down why it’s happening.
  - danabramov 4y ago
    The problem with logging a message is that it creates permanent console noise for people who enable it, thereby incentivising people not to. It seems like a small thing but people are very sensitive to extra logs. And if you allow silencing the log, we’re back to where we were.
    - tomduncalf 4y ago
      I guess I was imagining a single warning message at the top, “React is running in strict mode. This may result in you seeing console log messages twice. Read more here. Click here to disable this message for this site. Click here to disable this message globally”. Not too much noise really, especially if you can disable it per site or globally. I do see where you are coming from, I’m just thinking of my experience where I spent 30 mins+ thinking I’d found a bug or fundamentally misunderstood React all these years or whatever, and it turned out it was just the strict mode - but because I was using Next.js I never explicitly opted in, so had no way of knowing this might start happening (unless I read every release note). I’m guessing a lot of other developers using Next might be similarly confused!
captainmuon 4y ago
When React first came out, it was a breath of fresh air. There were some weird kinks, but instead of getting better they doubled down on the magic, and it got worse over time. I would really like something like React, but completely explicit - no hidden state, no hooks, no monkey patching. Everything class based, you have one render method, one method where you can launch your ajax, and you give your data dependencies explicitly instead of React trying to infer something and calling your functions at random.
- afiori 4y ago
  It would be enough for functional components to have extensible input and outputs function Button({props,ref,key,hooks}){ useEffect(hooks,()=>{...}) return {render: "text", ...stuff} }
  - imtringued 4y ago
    Yeah come on, the global hidden variables are completely unnecessary.
- KronisLV 4y ago
  > Everything class based, you have one render method, one method where you can launch your ajax, and you give your data dependencies explicitly instead of React trying to infer something and calling your functions at random. Class based components in React got pretty close. But for whatever reason, everyone jumped on the hooks bandwagon, against which i have some personal objections: https://blog.kronis.dev/everything%20is%20broken/modern-react-is-broken https://blog.kronis.dev/everything%20is%20broken/modern-reac... (harder to debug, weird render loop issues, the dev tools are not quite there yet) That said, using the Composition API in Vue feels easier and somehow more stable, especially with the simple Pinia stores for data vs something like Vuex or Redux.
  - imbnwa 4y ago
    Reginald Braithwaite had some really great responses to the move away from OOP as well: [0]http://raganwald.com/2016/07/16/why-are-mixins-considered-harmful.html http://raganwald.com/2016/07/16/why-are-mixins-considered-ha... [1]http://raganwald.com/2016/07/20/prefer-composition-to-inheritance.html http://raganwald.com/2016/07/20/prefer-composition-to-inheri...

by mbell 4y ago

btown 4y ago

This gets at something deeper: React has a policy of “in the dev environment anything goes; we will mess with your code and its runtime performance to help detect bugs or future bugs; you want us to do this, even if you think you don’t.” But this assumes good QA and staging environments exist and are used correctly. In reality, many users of React test on local and immediately deploy into production. The more the environments differ, the less friendly React is to these users. Timing issues and race conditions may surface in production. And thank goodness this isn’t Python where a log statement can consume an iterable if you allow it to do so! And for those saying “Strict Mode is opt-in” - your coworker may opt in your whole app without you knowing it. Hopefully you see the PR or the Slack thread. So much in React now enables this “spooky action at a distance.” The React team has put a lot of thought into balancing the performance needs of large codebases with the stability needs of smaller teams with less robust SDLC. I can’t think of a better workaround. But it’s still going to cause chaos in the wild.

andrewingram 4y ago
I agree with the sentiment of not being comfortable with dev and prod differents. That said, with React these dev mode differences are intentionally about making obscure production issues (such as timing ones) rear their ugly heads in development. The goal is that if your code works without issues in dev, it’ll work even better in production. It’s a thin line for sure, but I broadly support the way they’ve done it so far.
kmlx 4y ago
can be solved this way: - npm start when developing - deploy on dev using the artefacts from npm run build builds take a bit longer this way, but it guarantees QA will test using a non-dev build
- KronisLV 4y ago
  > In reality, many users of React test on local and immediately deploy into production. > deploy on dev using the artefacts from npm run build These two statements do not fit together. I agree that "You should have dev/test/staging/... environments" is the correct answer, but clearly that's not the reality for everyone.
  - kmlx 4y ago
    > clearly that's not the reality for everyone might not be the reality, but multiple envs is the only correct answer.

kristaps 4y ago

I agree, at first reading this sounds just plain horrible. I haven't tried doing any research, can anyone point out why it's not?

mhoad 4y ago

Broadly speaking I think React is in a weird spot where they have painted themselves into a corner with no obvious way of fixing it by essentially forking the DOM and doing so many things independently of the wider web platform. That approach made a lot of sense when it was first released but is just a liability at this point. If you’re deep in React land and it’s all you know I think 2022 might be a good time to expand your horizons a bit because the landscape around you has changed a lot in the past five years.

resoluteteeth 4y ago
> Broadly speaking I think React is in a weird spot where they have painted themselves into a corner with no obvious way of fixing it by essentially forking the DOM and doing so many things independently of the wider web platform. That approach made a lot of sense when it was first released but is just a liability at this point. The problems that strict mode is addressing with this somewhat unusual approach have absolutely nothing to do with the VDOM. Rather it is that code using React is subject to restrictions (being pure functions and following the hook rules when using hooks) that are impossible to express or enforce at compile time in javascript.
- mhoad 4y ago
  Sorry just to be clear, I wasn’t tying this to the strict mode situation but was attaching myself to the concept that this is just one of several points where the framework is showing some signs that it’s time to start thinking about alternatives particularly because I don’t think some of them are fixable at this point, they are just too central to the entire project and those decisions no longer make sense.
joeyjojo 4y ago
Outside of Vue, and maybe Angular, are there any other stable alternatives with a decent ecosystem? I'd love to hop off the React train, but I haven't found anything that compares to the experience of just using create-react-app with Typescript support.
- 4y ago

nightski 4y ago

It's not a "solution". It's more akin to a lint rule imho. Javascript provides no language level guarantees. There is no static type checker or compiler to enforce these things. So we rely on linters, tests, and assertions. Yay dynamic languages.

danabramov 4y ago

Thank you for the feedback. I agree this behavior was confusing. (We changed it to slightly dimming the second log in response to the community discussion. This change is released in React 18.) The new behavior seems like the tradeoff we dislike the least but new ideas are always welcome. Overall, we’ve found that calling some methods twice is a crude but effective way to surface a class of bugs early. I absolutely agree that it’s not the best possible way to do that, and we’re always thinking about ways to surface that earlier — for example, at the compile time. But for now, the current solution is the best we have found in practice.

tomduncalf 4y ago
Thanks for clarifying Dan. I think it might be appropriate for React to console.warn that strict mode is active (in dev mode) with a short description of this side effect, or perhaps the “dimmed” log message could have an explanation after it. Not all users have explicitly enabled strict mode (e.g. in my case I just started a new Next.js project) so this behaviour can be quite surprising and hard to track down why it’s happening.
- danabramov 4y ago
  The problem with logging a message is that it creates permanent console noise for people who enable it, thereby incentivising people not to. It seems like a small thing but people are very sensitive to extra logs. And if you allow silencing the log, we’re back to where we were.
  - tomduncalf 4y ago
    I guess I was imagining a single warning message at the top, “React is running in strict mode. This may result in you seeing console log messages twice. Read more here. Click here to disable this message for this site. Click here to disable this message globally”. Not too much noise really, especially if you can disable it per site or globally. I do see where you are coming from, I’m just thinking of my experience where I spent 30 mins+ thinking I’d found a bug or fundamentally misunderstood React all these years or whatever, and it turned out it was just the strict mode - but because I was using Next.js I never explicitly opted in, so had no way of knowing this might start happening (unless I read every release note). I’m guessing a lot of other developers using Next might be similarly confused!

captainmuon 4y ago

When React first came out, it was a breath of fresh air. There were some weird kinks, but instead of getting better they doubled down on the magic, and it got worse over time. I would really like something like React, but completely explicit - no hidden state, no hooks, no monkey patching. Everything class based, you have one render method, one method where you can launch your ajax, and you give your data dependencies explicitly instead of React trying to infer something and calling your functions at random.

afiori 4y ago
It would be enough for functional components to have extensible input and outputs function Button({props,ref,key,hooks}){ useEffect(hooks,()=>{...}) return {render: "text", ...stuff} }
- imtringued 4y ago
  Yeah come on, the global hidden variables are completely unnecessary.
KronisLV 4y ago
> Everything class based, you have one render method, one method where you can launch your ajax, and you give your data dependencies explicitly instead of React trying to infer something and calling your functions at random. Class based components in React got pretty close. But for whatever reason, everyone jumped on the hooks bandwagon, against which i have some personal objections: https://blog.kronis.dev/everything%20is%20broken/modern-react-is-broken https://blog.kronis.dev/everything%20is%20broken/modern-reac... (harder to debug, weird render loop issues, the dev tools are not quite there yet) That said, using the Composition API in Vue feels easier and somehow more stable, especially with the simple Pinia stores for data vs something like Vuex or Redux.
- imbnwa 4y ago
  Reginald Braithwaite had some really great responses to the move away from OOP as well: [0]http://raganwald.com/2016/07/16/why-are-mixins-considered-harmful.html http://raganwald.com/2016/07/16/why-are-mixins-considered-ha... [1]http://raganwald.com/2016/07/20/prefer-composition-to-inheritance.html http://raganwald.com/2016/07/20/prefer-composition-to-inheri...