I think McDonald's could have cared less. They made & continue to make $$$ hand over fist with these promotions. The marketing for sure worked, whether anyone won or not. I used to play these games & I never remember hearing about any real winners. Didn't keep me from the dream of pulling one of those instant winners. People get excited for games of chance and it drives large amounts of traffic into stores.
McDonald's counts those millions good as gone when they start the promotion, but it's worth it since they assuredly get a huge return on the investment. They assumed Simon marketing was doing their job, and we shouldn't be surprised they didn't care to look analyze the integrity of the game. They were selling truckloads of Big Macs & Mcnuggets and that all that really matters to them.
Any-who... great writing, and interesting look into to a "game" I'm sure most of us have a connection to. Pretty amazing it was hijacked by a few people for so long. Really enjoyed this read!
There is some irony in the criminals paying restitution to the company who was making so much money from the game to be incentivized to turn a blind eye.
Running the last game that was known ahead of time to be rigged seems indefensible. The article doesn’t challenge the position that catching the crooks is a good reason to defraud more people.
Finally, a us multinational who recognized the danger of Canada. So actually, the article didn't explain why we wanted to cut them out. It just was. I thought they suggested it was the marketing company, not mackers, but it wasn't specified.
As far as I know, most US-based companies don't like doing chance-based giveaways with the potential to have a winner in Canada. Even though it's not that hard, it's still extra work.
In this case though, the allegation is that the chance-based giveaway was still operated and promoted in Canada, but the prize-distribution was skewed so that no prizes went there.
Which, from a regulatory point of view, seems strictly worse than running an honest game.
Generally, Canadian law doesn't allow games of pure chance to be run for profit, outside of a handful of exceptions like the government-run lotteries.
So to run this type of promotion in Canada, you need to set up a façade of presenting it as a game of skill or mixed skill/chance instead, which usually involves something like having a prospective winner answer a math question. Look up "skill-testing question Canada" for more info.
And Québec in particular has piles of extra rules on top of that, which often leads to "offer not valid in Québec" as part of the promotion.
Great summary! I remember being young and seeing lottery tickets with simple math problems like “25 * 4 - 20 = ?” to get around the “no games of chance” laws.
My brother won a Sony Watchman (mini-TV) and we all double checked his math before redeeming.
That doesn't make sense as a motivation, though, because they followed those regulations anyways. They ran it in Canada every single year. Heck, last year they customized it by renaming all of the pieces after Canadian landmarks [1].
I expect people said this about developers that just knew about TCP/IP and not how the PHY worked.
At every level of abstraction they is a boundary that people may not choose (or have time) to pass.
I'm not saying everyone should be forced to learn about every layer, but these knowledge boundaries exist everywhere, and I'm not sure what can be done to improve the situation...
There's no problem with not knowing the deeper/higher layers. The problem is when someone outright ignores their ignorance, when someone doesn't even acknowledge their boundaries. And when those boundaries are set in stone. ("I won't touch the terminal." or "I won't touch C." or "I won't touch CSS.")
This is (unfortunately) a huge testament to patenting technology. I remember Shazam shutting down a lot of early iOS apps that provided music discovery services. The technology it’s self became relatively simple in the last 10 years, but their ownership of the patent has kept them on top.
I suspect it’s due to end soon, and they realised once it’s gone they would just become a feature of music streaming services. Good to get out now while there is still some exclusivity for Apple to milk.
There is a certain paradox with teaching something like Redux, in that it's designed to make complex systems easy to understand and manageable. Yet when trying to demonstrate with a simple example, it appears hugely over complex and unnecessary.
I think a pre-requisite to learning something like Redux (or any micro-architecture) is to first try building something without it. Once you understand the pains of undisciplined, organically designed, spaghetti applications, the cynicism is replaced by excitement over how this will improve your job/life/application.
Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not.
When programming JavaScript SPA, you can program in the style of MVC also. There is no need for actions, reducers and so on, unless your app is for example a word processor and you need undo/redo (as mentioned by another comment on this thread.) Most of the time you are getting data from the backend, temporarily storing stuff in memory, modifying it and sending it back to the backend. There is no need for actions/reducers and such other nonsense for that.
When I mention this someone always points me to the "you may not need redux" article by the creator of redux, in an attempt to legitimize some use cases of redux. There may indeed be some legitimate uses cases for redux. But it has become the de facto standard way of building React applications, and that's totally unjustified.
In the apps that I've built, having many components manage their own private state makes it hard to coordinate said components, because all of the application state is stuffed inside different jars that you can't easily peak into.
It's been much easier to pull all app state into a central, db like structure, and allow components to connect and query that structure for whatever data they need. It makes making changes to components in the future easier, because all of my data is normalized in a structure, and it's all possibly available to any component in the app.
I've found that with MVC, if you design the private state a certain way, and in the future need largeish independent components to coordinate, well, you're going to have a bad time.
So redux or not, I'm definitely a fan managing state as it's own separate thing, and having components able to query and connect to that data structure, without having to pipe props down a tree of components, which leads to an app that's hard to change.
Agreed! Redux is cool but often overkill for basic CRUD apps, which the majority of JavaScript SPAs tend to be. My approach has been to take a long look at the app structure - if there's a way to refactor it to remove Redux (or what have you), that's probably the most sensible thing to do. Simple code > clever code where performance and maintainability are concerned.
I wouldn't mind a use case where Redux would be necessary or at least beneficial, for the practice, but I've yet to run across it after building half a dozen or more SPAs. These would be enterprise SPAs used in production, btw.
Hey, this is a bit tangental but since you mention building enterprise SPAs I'll guess your experience will be able to help me. So, I'm not as experienced but can get around to learning any code and as I need to start building a portfolio I dove in again to build one. But things were breaking and I couldn't get rolling as fast I thought and although for a longer term bigger project I would spend the time tweaking I want to get something up fast and thought that I need to use a simpler tool. So, I'm curious what to you use to build your SPAs? What's the process like for you? Thanks
MVC isn't especially easier than event sourcing (which is basically what redux is) once you get to larger applications. I think the two map quite nicely onto Fowler's design stamina theory (https://martinfowler.com/bliki/images/designStaminaGraph.gif) in that redux is harder to work with for small apps but the complexity scales linearly. MVC is easy for small apps but has a tendency towards spaghetti in larger codebases.
>> MVC is easy for small apps but has a tendency towards spaghetti in larger codebases.
Disagree. There is no reason to believe MVC tends towards spaghetti in large codebases. Controllers and views implement a small portion of the application's functionality. When the applications get larger individual controllers and views do not even know that the application got larger, so this scales very well.
It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is going on because effects are interleaved with logic, even when each component individually feels decoupled and nice.
What Redux/value-based data model does is to really separate those concerns. Your update logic is a function that just can mess all it wants with the new values it produces. It is composable because you can just build logic by calling smaller logical unit and you know everything you need to know by looking at the inputs and outputs.
It is way simpler (and less!) code in all but the most trivial of the examples.
If your model layer objects are firing events you have problems already because it obscures the call graph. I try to avoid that style. The controller should update the model objects, then if a view update is needed it should be triggered by the controller not the model layer object.
Then your controller needs to know about 1) all existing views and 2) all effects of model update logic. Again, you end up with low decoupling with points that you can only change with global knowledge (and lots of potential effect interleaving). If you already have a "plain data" model, the next logical step is to just get rid of stateful controller and use a simple data-flow Redux-like flow for updating the UI.
I give in that the tricky part is finding UI frameworks that play nicely. You need something React-like to efficiently re-evaluate the Model -> UI functions, or use an immediate-mode API. Alternatively one can manually write some function to update a stateful UI by comparing the previous and current model and often it's enough. It is a bit like your controller but it is agnostic to the specific actions that happened but just look at the model changes (i.e. no global knowledge needed). I recently discussed this here:
We were precisely talking about composition and now you say there is only one? I guess you are talking about small apps where you have small dedicated views?
That is a very narrow definition of MVC. I am talking of large interactive software with multiple views on large hierarchical data trees data with different levels of focus and granularity. The kind of software I am thinking of big programs like Photoshop, Premiere, an IDE, Ableton Live...
Disclaimer: I worked for Ableton for quite a 5 few years, and have spent most of my career building interactive software (I work as independent consultant now). Most of the software of that time and age is built around MVC. It kinda works, but as a lot of people in the industry building software of that size will tell you: scale brings the the pain. Because of composoability. In the C++ world, see also talks from Sean Parent--who worked on Photoshop--and is also a strong proponent of "value-based" approaches (he is a great source of inspiration for me). Sean claims that something like 70% of bugs in Photoshop are in UI-related code typical MVC wiring up stuff.
In the end, just pick the right tool for the job. If you are writing small apps and MVC does not explode at that size and fits nicely with the underlying frameworks, go ahead and use it (I strongly suspect you are an iOS dev and understand how conformity with the native framworks is very important there).
But if you are building something large, highly interactive, with lots of views and concurrency, try to move to a more declarative/unidirectional flow/functional approach. It is still an open field and there are many alternative approaches, but it builds down to composability, denotational reasoning and decoupling of effects/logic.
@arximboldi, I wouldn't use MVC for implementing something like Photoshop or and IDE, that's not the kind of application MVC is good for. MVC works well for applications that navigate through multiple screens.
Yea basically this. Built a 'big data app' using Ember, which was all well and fine until some of the routes essentially became their own apps, that were more akin to apps like photoshop. MVC really broke down for us here, and it wasn't until we introduced react / redux and slowly refactored the application until things got more manageable and sane.
OOP was very different in smalltalk too. Industry software dev has really strayed away from the theoretical origins it was based in, although I think the tide is starting to turn back now.
It scales well in theory, and as long as the devs understand separation of concerns, and keep on top of refactoring, and don't overcomplicate things with extra layers of abstraction.
I've worked on some Angular (1) apps that became very messy over time. I think it all depends on the project. React/Redux can get messy too.
the things I find scale badly in MVC are primarily related to general OOP scalability issues - dependency hell, bloated classes, loss of separation of concern, and the big one being poor cohesion and state mutation propagation. I think my argument is broadly more like "OOP is needlessly hard", something that isn't really inherent to MVC.
I think the main problem is that MVCs aren't really a good way to write interfaces. You have so many state values that needs to be stored somewhere (dropdowns, input values etc). I'm not saying that redux is a good use-case everywhere but trying to write MVCs on the web is not a good fit. React is not a MVC library and not only the view part of it either...
This paradox I think is what turns people off Redux when they first learn it. "All this code... for what benefit?" Of course it's total overkill for something like a counter, or a todo list, but it's tough to teach an introduction to something by starting with "here's a huge enterprise app, let's dive in" :)
I tried to call this out in the article to make sure people are aware that improving simple Counter examples is not what Redux is really meant for.
I'm considering putting together a larger course/book that does just what you say - build up a React app using plain state until it becomes painful, and then refactor it to add Redux. My question right now is, how far should I go? Do I walk through building the entire app with state (and push through the complexity), or do I give up at the first indication that Redux would make things easier?
I understand the value of redux but I'd lump it in with git as an invaluable and elegant solution with a terrible interface. The structure is very confusing up front and makes no sense to an outsider. I learned react in about 15 minutes because it's so intuitive, but redux keeps making me scratch my head.
IMO, It's a fundamental flaw with JavaScript that interfaces aren't rigorous or discoverable and redux is a willing victim.
I think it's mostly react-redux. There's arcane boilerplate in the connect function, mapDispatchToProps looks like a leaky abstraction, actions being passed as objects with a string in them is super brittle.
I don't have a fix, but I think just being able to inject a link to the store and then having an API that can be manipulated directly from the component would more comprehensible and cut down on the layers of indirection. I typically see corresponding action, reducer js file for a component when 95% of the logic is already in the component. Just merge them.
Appreciate the feedback. Could you give specific examples of what you mean by "arcane boilerplate" and "leaky abstractions"? We don't have any plans to change the actual API, but I would genuinely be interested in any suggestions or concerns you have with it.
It's also worth noting that I personally highly recommend consistently writing separate action creator functions [0], and using the "object shorthand" argument to `connect` instead of writing a separate `mapDispatch` function.
That said, it also seems like part of what you're concerned with is the fundamental design of Redux. The use of plain object actions as a layer of indirection is deliberate [1], and it's what enables capabilities like time-travel debugging. Actions need to be serializable for that to work, and therefore strings are the best solution for the action's `type` field [2].
You certainly don't have to keep _everything_ in Redux. You should consider whether a given bit of state should live in Redux, or in a component's state [3]. But, if you _are_ going to keep data in Redux, then actions and reducers are necessary for the Redux data flow. They don't have to be in separate files [4], but they need to exist to update the store.
I guess it's a matter of taste, but using object shorthand for an API seems like and anti-pattern. APIs are where a rigorous definition is most valuable. Like I said, it works fantastically well once you get the hang of it, but try showing this to a newb and ask them to trace it. Nightmare.
I'm not being a grump either. I coded Perl professionally for over 5 years and am well-versed in terse, functional idioms, but the community rightfully decided that strings of punctuation were too obtuse for practical use.
> Once you understand the pains of undisciplined, organically designed, spaghetti applications, the cynicism is replaced by excitement over how this will improve your job/life/application.
Beautifully said. The same goes for schema-less data models. The full appreciation of foreign keys, data type validation, and check constraints doesn't kick in until you try incrementally changing a NoSQL spaghetti app.
Similarly, I've always liked javascript's dynamic and flexible nature, especially for ui programming where requirements evolve quickly and dramatically. But now that I've got a big redux app that is on a pretty steady course, I'm starting to see the value that static types would bring. A lot of the mental overhead of working with the codebase now consists of remembering the exact shape of all the data, which properties are defined on which actions, etc. Before too long I'm going to have to give Typescript, Flow, or something along those lines a serious look just for the sake of having it all defined in one place.
I've been singing the praises of Typescript since the first day I started playing with it. Easing into it from a JS codebase is pleasant enough, but greenfield development with typing everywhere is incredible. I highly encourage checking it out sooner rather than later.
This is exactly what happened to me and I'm glad I did it. My intro to programming was a nightmare jquery app. Then a slightly better Backbone app with too many Globals. Then an over engineered Sails app. And now a collection of React + Redux apps, multiple years old, each with increasing levels of maintainability.
I'm hesitant to see new programmers avoiding a "learn the hard way" project. Without it, there's so much they might never grok.
I think there's a fair criticism of Redux in here - most well designed tools can accomodate a learning curve, and scale up the complexity when needed. I can be productive in Express without knowing about middleware, or git without knowing how to rebase.
Redux, on the other hand, expects you to dive into the deep end head first the first time you use it. I teach javascript development, and I'm noticing there's a pretty big gap where you're feeling the pain of React, but Redux is still too large a complexity tax (To be fair, even to an experienced programmer it often is - for every complex state change that warrants Redux there's 50 straightforward "change this field" or "toggle this boolean" actions.)
Maybe this isn't the responsibility of Redux, and something should be built on top of it, but there needs to be some amount of consensus on what the best solution is.
The Redux learning curve is tough, especially for folks who don't already have a strong grasp of functional programming ideas. Immutability is weird. Breaking everything up into multiple places (dispatch, actions, reducers) is weird. Like you say, it's unfortunate that one must basically learn _all of it_ to get started using Redux. It does do a nice job of solving difficult problems though.
> there needs to be some amount of consensus on what the best solution is.
The thing is, there is consensus: it's Redux. I'm not saying that's good or bad, but it's king of the state management hill right now.
What's really interesting to me is that the JS community is largely allergic to anything that isn't the "best solution". Nobody wants to use a little library with 53 stars on Github, even if it's easier, or seems like a better fit than Redux. The thinking seems to be "It's not any good unless it's the most popular choice." Those sorts of libraries might be ok for proof-of-concept work, but not for the real world. Not for production.
What drives this line of thinking? I think it's complex, but I believe fear plays a big role.
- Fear of choosing the wrong library (what if it becomes unpopular!)
- Fear in one's own abilities to evaluate a library ("it seems fine to me, but I'm no authority, I can't make that call")
- Fear of looking bad to the boss ("Nobody ever got fired for buying IBM", right? React + Redux has that spot right now)
There's also the self-reinforcing nature of a popular thing: companies using Redux => job listings require Redux => people want to learn Redux => people make Redux courses/books/blogs => people don't teach the alternatives.
There's consensus on Redux - that's not what I'm talking about. There seems to be a fair amount of desire for something that simplifies "straightforward" state management. The Redux maintainers don't seem to be interested in this, preferring it to be something created by the community. As far as I can see though, no one is filling that gap.
I'm a Redux maintainer, and I'm _absolutely_ interested in making it easier for people to get started with Redux. I opened up an issue thread earlier this year to get community feedback and ideas on how we can do that: https://github.com/reactjs/redux/issues/2295 .
We don't plan to modify the Redux core itself, but I would _love_ to be able to list some tools as "approved" or "blessed" ways to get started easier.
Sadly, I just don't have enough free time to go build much of anything like that myself, but I will happily work with anyone in the community who's interested in doing so.
I also hope to revamp the Redux docs "Ecosystem" page to more specifically point to certain tools as recommended solutions to specific problems, but again haven't had time to do so yet.
It's downright embarrassing to walk through a Redux-using project with someone competent who's not immersed in the JS world. Source: had to do this recently. It helps if you translate "action creator", "action", and "reducer" to terms that are less misleading in the first two cases, and less uselessly-generic in the last one, but only a little.
I tolerate it for basically "no-one got fired for buying IBM" reasons, i.e. the devs I work with think it's good and it's better to have twice as many problems and none of them be my fault than half as many and all of them be my fault.
I would expand that to say, it's embarrassing/difficult to explain the JS ecosystem to experienced non-JS devs. From "why are there 132MB of packages for hello world?" to "why is there a build process at all", people outside the UI+JS world have a tough time seeing why there's so much complexity for "just the UI".
Also, side note, it's hilarious (and maybe telling) that we both referenced the "no-one got fired for buying IBM" quote...
As an old-school Java dev that's been pulled into the JS world kicking and screaming, I can say that I have a pretty good appreciation for most of the complexity around modern FE builds. NPM legitimately kinda sucked up until the last few releases and is now stabilizing. I get functional programming. I even advocated for react when it was new because it felt so natural and powerful. Redux (or really react-redux) just hasn't hit that sweet spot. That being said I've seen it be hugely successful on big projects.
I perhaps foolishly go ahead and teach React and Redux to my students. The first thing I show them, however, is this article by Dan Abramov, who you perhaps know from his conference videos or his amazing work fielding React bug reports.
Earlier this year, I opened up an issue to get community discussion and feedback on ways to "reduce boilerplate" and make the getting started experience easier: https://github.com/reactjs/redux/issues/2295
The discussion trailed off, but I'd love to get additional feedback and ideas on ways we can improve things and build easier-to-use abstractions on top of Redux. (Or, even better, get some volunteers to _help_ us build better tools for getting started.)
Yeah, personally I use it - I think it hits the sweet spot of making simple things simple while still allowing for complexity perfectly.
It's a shame I can't really teach it, however - the fact is, it doesn't have enough mindshare right now and part of the reason people take courses is to learn marketable skills. For better or for worse, nearly every React shop is looking for devs who know Redux.
Just went through this myself, and that was exactly my experience. Really glad I spent time working with React so I knew what Redux would be great for before I tried to learn it.
My only experience of using Redux was in a completely inappropriate application and I really came to hate it, but I can see how it'd be cool if you wanted to do like... a word processor or something where you wanted an undo/redo chain.
I agree with this. I tried to learn React and Redux a while back, and didn't really grok it, so I built the React app without Redux. Ended up passing state up and down many, many layers of components and it got pretty hairy. So I added Redux to the mix and it was like a lightbulb went off in my head.
That's because you used React Router, which makes the router a view component. Router should be independent of view technology. If you had used React in the MVC style you would not have had to use Redux. Think about how session state works in the case of server-side applications. The same can be done on the client side too, by using React with an MVC framework.
What this will let you do is basically extend your server-side GraphQL API with a set of local resolvers for queries and mutations, and let you query and mutate both your server-side and client-side state using a single consistent API (GraphQL, with client-side fields decorated with a @client directive), backed by a (mostly) automatically normalized local state cache (by default apollo-cache-inmemory, but customizable, so you can even implement a Redux based cache if you'd like more control).
A lot of the complexity in Redux today stems from the need to reconcile client-side state with server-side state, usually fetched through some kind of async actions paradigm like Thunks+Promises, Saga, Observables, etc, to be then manually merged into the local state after being transformed into a normalized form.
I personally think one of the biggest problems with the design of Redux is that the architecture derives most of its benefits from having a normalized state tree, but it also makes it all too easy for developers to store non-normalized data in the state tree. Although admittedly an architecture that does enforce a normalized state tree would be an order of magnitude more difficult to learn and work with in the wild-west of RESTful APIs that used to be the de-facto norm back in the days when it was designed (and it still is, though that may be slowly changing with the rapid adoption of GraphQL), where most server-side data you receive isn't easily normalizable to begin with.
A good GraphQL client like Apollo can already abstract away much of the complexity involved with async server requests through its Higher-Order Component-based API, which simply provides data to the wrapped component as props, so it doesn't need to know how to fetch that data. More importantly though, Apollo also ensures that all the server-side state it maintains in its cache is stored in a normalized manner, and GraphQL makes this fairly easy.
Apollo-link-state goes a step further and allows you to use the same abstractions for managing client-only state, and store it in a normalized form alongside your server-side state, to allow for a much more consistent and comprehensive state management API.
With all that said, apollo-link-state is still really young and I've only played around with it briefly in toy projects, so there's no guarantee it could scale as well to large teams as Redux has. I do still personally find it to be one of the most promising alternatives out there though.
Lastly, Relay Modern also supposedly has something called Client Schema Extensions, which I assume is similar to apollo-link-state, but wasn't able to find any documentation on it outside of a brief mention in its release notes: https://facebook.github.io/relay/docs/new-in-relay-modern.ht...
