4 ms·

> How do you find out which part of your code set your global mutable state object Generally, it's easy. My state variable represents a single concept in my pr

> How do you find out which part of your code set your global mutable state object Generally, it's easy. My state variable represents a single concept in my problem domain, so there's usually only a single source of truth that would ever update it. > What if two or more bits of logic try to set this variable at the same time Generally, this will only happen if the variable is actually a derived property, rather than a primary one. I handle this by making my primary properties observables, and my derived properties read-only computeds. Taking this approach, I don't think I've ever had the quandary you describe, and I've built everything from very thick SPAs to very thin and nimble content sites. > How will you control that `myvar` can only be set to particular values dependent on other state? It seems to me a matter of simple discipline. > How will a QA engineer demonstrate to you that it was this state change which broke your application? She might write a failing test case, or use the debugging tools I've added to the console. She certainly wouldn't mess about with something as proprietary as Redux devtools, because at that point I'll be unable to move to better JS technologies without getting cross-team buy in. At most companies, that basically means it just won't happen.

lhnz 9y ago
Your solution is for everybody in your team to maintain a high level of discipline and for QA engineers to use homegrown debugging tools you've added into the console. You have effectively advocated for both NIH syndrome and a social solution to a technical problem (effectively "it is possible to write error-prone and difficult to debug code so we should ask everybody in the team to be more disciplined" vs. "lets make it impossible to express error-prone logic, and lets make it easy to observe our state"). I think Yaron Minsky's "Make illegal states unrepresentable" is appropriate here.
- jbreckmckye 9y ago
  From where I'm sitting, your reply looks a lot like an insult. I hope I'm just reading it badly, but as is, I don't think we're going to have a productive discussion.
  - eropple 9y ago
    Where is he insulting you? It reads as a pretty even-handed extrapolation from your assertions. Maybe a little incredulity, but your assertions are a little incredible.
    - jbreckmckye 9y ago
      Maybe they are incredible. I suppose the reason I don't 'get' Redux is probably that I don't 'get' the problem it claims to solve. Redux developers seem to say their issue with prior frameworks was that it was difficult to understand where state changes came from. But that's just not an issue I've had in the apps I've built. Maybe the apps I call 'thick client' really aren't? Then again, I've done a fair few gigs in this game, on lots of kinds of projects, so I'd expect by now to have the perspective to say which was which. That experience also makes me a little stubborn. I've had a few exchanges like this, where people have reacted with incredulity. They remind me a little of the arguments I had convincing people to abandon 'semantic' CSS, or grouping templates and view logic into components. I think history was on my side, at least in those cases, so I no longer feel abashed to walk against the crowd.
      - simon83 9y ago
        > Redux developers seem to say their issue with prior frameworks was that it was difficult to understand where state changes came from. Prior to React/Redux we used two-way data binding with first kendo then Knockout.js in a non trivial SPA. It was a nightmare to figure out where certain change events came from. It became a big ball of (un)observable spaghetti. Now you will tell me that our problem was that we let it come this far, and I totally agree with you, but the whole app was started years ago by inexperienced web developers (they were C/C++ devs), then it grew historically into an unmaintainable monster. This was long before I joined the company, and my team is now like the 4th generation working on and refactoring that code. Redux makes it laughably easy to figure out where state changes come from. Not only that, but time travel debugging is a thing. For the parts that are mostly React/Redux, we made a little debug UI for QA so that they can serialize the last n states, send it to a database and automatically link it to issues. It's still more or less a proof of concept and not as useful as it could be, because not everything is stored in Redux yet, but it did show us that once we are where we want to be it will be an incredibly useful tool to reproduce bugs. Besides that writing unit tests for React/Redux is also easy, compared to other libs/frameworks. May I ask with what kind of technologies you've been working with so far? Because reading your comments gives me the impression you live in a perfect world, with highly experienced and disciplined team mates, with no problems what so ever. If so congrats, you've won the lottery I guess.
- baybal2 9y ago
  I fail to see how is any framework code is easier to debug than vanilla js. React is pain to debug unless internal React error catching logic fires With vanilla js, things are as simple as putting breakpoints in code and running it in Chrome's standard debugger
  - simon83 9y ago
    I'd love to see the code of your vanilla js SPA :) Or does the server render the HTML, and JS just adds a little bit of interactions? Because then you are right, you may not necessarily need React (but it can also render on the server)

lhnz 9y ago

Your solution is for everybody in your team to maintain a high level of discipline and for QA engineers to use homegrown debugging tools you've added into the console. You have effectively advocated for both NIH syndrome and a social solution to a technical problem (effectively "it is possible to write error-prone and difficult to debug code so we should ask everybody in the team to be more disciplined" vs. "lets make it impossible to express error-prone logic, and lets make it easy to observe our state"). I think Yaron Minsky's "Make illegal states unrepresentable" is appropriate here.

jbreckmckye 9y ago
From where I'm sitting, your reply looks a lot like an insult. I hope I'm just reading it badly, but as is, I don't think we're going to have a productive discussion.
- eropple 9y ago
  Where is he insulting you? It reads as a pretty even-handed extrapolation from your assertions. Maybe a little incredulity, but your assertions are a little incredible.
  - jbreckmckye 9y ago
    Maybe they are incredible. I suppose the reason I don't 'get' Redux is probably that I don't 'get' the problem it claims to solve. Redux developers seem to say their issue with prior frameworks was that it was difficult to understand where state changes came from. But that's just not an issue I've had in the apps I've built. Maybe the apps I call 'thick client' really aren't? Then again, I've done a fair few gigs in this game, on lots of kinds of projects, so I'd expect by now to have the perspective to say which was which. That experience also makes me a little stubborn. I've had a few exchanges like this, where people have reacted with incredulity. They remind me a little of the arguments I had convincing people to abandon 'semantic' CSS, or grouping templates and view logic into components. I think history was on my side, at least in those cases, so I no longer feel abashed to walk against the crowd.
    - simon83 9y ago
      > Redux developers seem to say their issue with prior frameworks was that it was difficult to understand where state changes came from. Prior to React/Redux we used two-way data binding with first kendo then Knockout.js in a non trivial SPA. It was a nightmare to figure out where certain change events came from. It became a big ball of (un)observable spaghetti. Now you will tell me that our problem was that we let it come this far, and I totally agree with you, but the whole app was started years ago by inexperienced web developers (they were C/C++ devs), then it grew historically into an unmaintainable monster. This was long before I joined the company, and my team is now like the 4th generation working on and refactoring that code. Redux makes it laughably easy to figure out where state changes come from. Not only that, but time travel debugging is a thing. For the parts that are mostly React/Redux, we made a little debug UI for QA so that they can serialize the last n states, send it to a database and automatically link it to issues. It's still more or less a proof of concept and not as useful as it could be, because not everything is stored in Redux yet, but it did show us that once we are where we want to be it will be an incredibly useful tool to reproduce bugs. Besides that writing unit tests for React/Redux is also easy, compared to other libs/frameworks. May I ask with what kind of technologies you've been working with so far? Because reading your comments gives me the impression you live in a perfect world, with highly experienced and disciplined team mates, with no problems what so ever. If so congrats, you've won the lottery I guess.
baybal2 9y ago
I fail to see how is any framework code is easier to debug than vanilla js. React is pain to debug unless internal React error catching logic fires With vanilla js, things are as simple as putting breakpoints in code and running it in Chrome's standard debugger
- simon83 9y ago
  I'd love to see the code of your vanilla js SPA :) Or does the server render the HTML, and JS just adds a little bit of interactions? Because then you are right, you may not necessarily need React (but it can also render on the server)