Hacker News Reader

Comment by lhnz | Hacker News Reader

  this.app.globals.myvar='selected'

How do you find out which part of your code set your global mutable state object (e.g. `this.app.globals[propertyName] = stateType` or `$globals.myvar = 'selected'` or `window.app.globals['myvar'] = 'selectedd'`)? What if two or more bits of logic try to set this variable at the same time and it ends up with a value that you didn't expect? How will you control that `myvar` can only be set to particular values dependent on other state? How will a QA engineer demonstrate to you that it was this state change which broke your application?

Your 'solution' is a bad practice, and Redux is a huge improvement over it.

View on HN

> 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.

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.

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.

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.

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.

> 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.

What Simon describes here is why stuff like event log datastores (Kafka, mostly) and CQRS-patterned systems are becoming so powerful, too. If you can just say here is every event that has gone through the system modeled as unambiguous transforms on immutable state, replaying--for both DR and debugging--is a trivial and super helpful exercise.

"thick" client is really meaningless term, when it can mean anything between "5k+ LoC" and "100k+ LoC". I'd argue redux is best used for projects closer to that upper bound.

But I don't have real experience with it. I just extrapolate from general overusage of strong (but inappropriate for smaller projects) tools in JS world and subsequent annoying whining about "JS fatigue".

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

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)

It's such a dead simple solution that it's never been a problem. Certainly doesn't warrant replacing with all the code and complexity of Redux, which introduces its own demand for testing and QA, and I would argue offsets its own value due to its complexity.

In software development simple = understandable and reliable.

But I just demonstrated that it's not understandable or reliable. You are proposing a solution where any badly written code can affect your global state in a way that you can't control for, and in a way that you will not be able to search for.

Eventually you are going to get bugs, and you are going to have a hard time tracking them down for the reasons I've described.

It might be okay if you work on small projects without many team members, but in larger projects it's extremely annoying to have these kinds of issues.

I wonder if it's maybe the architecture of my application that means I don't need to store much state, and I only store state that doesn't seem to subject my app to the issues you describe.

When I hear about these apps with a heavy reliance on client side state I wonder what the heck they are doing... if you've got so much complex data/logic does it really belong in client state? I'd see it as a problem and try to architect it out, or store it somewhere.

It's absolutely possible to do something that has the issues I'm describing and never see any bugs because you are disciplined and careful. However, as a contractor, I have worked with plenty of teams where due to horrible deadlines and sloppy practices all of the problems I've described have occurred. Basically: once you climb over the learning curve, Redux helps you here.

> Eventually you are going to get bugs,

I read:"Sometimes you are going to get event bus." Indeed sometimes simple event bus (pub-sub etc.) could be sufficient for replace Redux. EventEmitter is already a dispatcher. And then you can easily listen to each event in your app, like in Redux.

I think the key to the scalable apps is good architecture (and correct design patterns), not framework.

And Redux is good as education tool. It encourages people to use one global event bus("dispatch" function), it educates about principles of functional programming. It shows people advantages of event sourcing and CQRS. I think the most value of Redux is that people got educated.

But I don't think Redux (at least Redux alone, without Redux-saga or other solutions) is good tool for use in production code. It's too low level. Too many moving parts. No clear way "what should go where". And JS sucks when comes to immutable code (either Object.assign / ... mess or necessity of using third part library like Immutable.js)

Additionally people don't know how to use it properly. Redux codebases are usually much worse than Redux really demands (e.g. people use ugly switch/case despite the fact in Redux docs there are instructions how to get rid of them: http://redux.js.org/docs/recipes/ReducingBoilerplate.html#ge...

Reply on news.ycombinator.com