Reactions: Making Things Simpler with React and Flux
•Download as PPTX, PDF•
0 likes•859 views
A talk about heuristics, simplicity, and the React/Flux mindset from Code on the Beach 2015. The slide notes contain my talking points.
![Software Engineer & University Liaison at feature[23]
Graduate of Florida State and North Florida with respective
degrees in Music and Computing
Prior professions include martial arts instructor, fishing guide,
touring guitarist, and I am still regularly involved in
professional drinking](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Reactions: Making Things Simpler with React and Flux
- 1. Reactions Making Things Simpler with React & Flux
- 2. Software Engineer & University Liaison at feature[23] Graduate of Florida State and North Florida with respective degrees in Music and Computing Prior professions include martial arts instructor, fishing guide, touring guitarist, and I am still regularly involved in professional drinking
- 4. Heuristics
- 5. JavaScript “JavaScript is the heuristic that no matter how amazing of a programmer you think you are, you are… “Uncaught TypeError: undefined is not a function.
- 10. So, Why React (and Flux)?
- 11. Simplicity
- 12. How do we convince people that in programming simplicity and clarity — in short: what mathematicians call "elegance"— are not a dispensable luxury, but a crucial matter that decides between success and failure? Edsger Dijkstra
- 13. What Can Cause Complexity?
- 14. Abstractions
- 15. Too Many Abstractions “All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection.”
- 16. Abstractions Can Be Limiting
- 17. Choosing the Right Abstractions
- 18. Data Fetching & Persistence
- 19. Rendering
- 20. Data Flow
- 21. We Shape and Create Data Flows
- 22. So… What Does Simple Look Like Then?
- 23. PresentationData
- 24. Flux React
- 26. Data Flow PresentationData (Potential) Abstraction Abstraction The heart of your application
- 27. The Flow
- 31. Unidirectional data flow Declarative/Explicit Mutation Public APIs for retrieving data (and registering for mutation events) CQRS & DDD (inspired) for client-side development
- 32. Code
- 33. The War Between The States
- 34. Data Presentation Application State View State
- 36. f(simplicity, reliability) => confidence
- 37. Questions! Like, why not “!?!” instead of just “!” ???
- 38. Resources GUI Architectures (Fowler) Observer & Flow Synchronization (Fowler, again) Separated Presentation (Why not Fowler?) History of MVC React & Flux Vanilla Flux (shameless self promotion) Redux (brilliant talk on future of Flux)
Editor's Notes
- So, I’ve been a software engineer at feature[23] for about three years now, and I also do quite a bit of work with UNF, helping bridge the gap between the academic and the real world when it comes to Software Engineering. I have two degrees… one that makes money, and one that doesn’t… I’ll let you figure out which is which. I have previously worked as a martial arts instructor, fishing guide, touring musician, and I’m still active in the beer industry.
- So, what are we going to talk about today? Web Development. Let’s ask Old Man Developer what he thinks about Web Development. Old Man Developer holds such opinions because that’s either what Best Practices say, or he’s formed his own set of Heuristics based on his experiences in Web Development. Regardless of your current opinions and heuristics on Web Development, I’m hoping that today’s talk has a positive influence on them, or at least gets you thinking a bit differently.
- To kick things off, let’s briefly talk about Heuristics, as they'll be an integral part of today's talk. Heuristics are defined as using experience to learn and improve They’re generally referred to as a rules of thumb, again, because they are primarily based on prior experience or knowledge and this means that they may not always provide the most optimal solutions... But they’re typically the best we can do, given our experiences. Aside from all the technical reading and research we do, or should do, all we really end up with in the wild are our own heuristics. Today, I’m going to present what I think are some good heuristics in JavaScript Development, and development in general for that matter But before we get too far into the high brow philosophical stuff, let’s all put on our collective dunce cap and enter the wacky world of JavaScript
- I could go on and on about all the ridiculous mishaps that you’ll find in this “programming language” …But I’m not going to waste your time making light of JavaScript’s shortcomings…. Of course I am. Now is the time for the requisite JavaScript bashing.
- JavaScript is much like a Japanese game show, in that you might actually die while participating. The danger is seriously palpable. In describing epic JavaScript fails, Brendan Eich used the term “footgun” to describe a fictitious firearm that is presumably attached to one’s foot, with the end result being a podiatric disaster. So, instead of a game show, you can think of JavaScript as this George Miller-esque dystopian wasteland where everyone is strapped with two footguns, headmines, and brain launchers. Maybe it’s more like the Saw movies? Whatever. If you haven’t already, visit http://wtfjs.com/
- Anyone know what this code will do? ??? It will fail miserably. Is it obvious why it will fail? Yes, r is style a property, it's actually defines the radius for SVG elements. This fails because getElementsByClassName returns a NodeList. NodeLists are one of those really nifty things in JavaScript called “array-like” objects. You get properties like length, but since they don't inherit from Array's prototype, you can't call Array methods on them. You have to iterate them with things like for and while loops.
- So, what inevitably happens on every project, is some well intentioned and highly motivated young developer charges in and says… “I know, we’ll add that hot new JavaScript framework to our application and all of our problems will be solved, we will deliver way ahead of schedule, and it will be SO much fun to code with!!!” Meanwhile, the poor team lead, who should have been guiding the direction of the project based on his or her heuristics, is then passenger to Mr. Eich’s Wild ride, until the lone person in the building that remotely understands JavaScript saves the day… …or the client pulls the plug on the project.
- And when you eventually ship your product with JavaScript, and it’s time to celebrate, JavaScript responds to your elation with a pride obliterating pimpslap as your application crumbles in production because… well… JavaScript.
- So why in the hell am I up here arguing for more JavaScript? Because JavaScript isn’t really the problem, it’s just a comical scapegoat. The real problem is Complexity in your JS Applications, and the answer is moving toward Simplicity.
- In his talk, Simple Made Easy, Rich Hickey states that Complexity undermines understanding. He also states that simple is not equivalent to easy. Simplicity does equate to a lessening of cognitive load, which has the invaluable result of better decision making. The more esoteric the concepts at play, the less your teammates will be able to $digest them (no pun intended) as a whole. Or is that $apply? I'm really aiming to avoid dumping on other frameworks today ($digest is just too easy) Unless your team is made up of five Jon Skeets, I imagine you have a team lead, and engineers of varying skill levels There are probably some juniors on your team You expect them to deliver value But you've chosen a framework loaded with esoteric concepts in a language that is about as reliable as it is good at dealing with Dates and Math Why not give them something that is simple? Something they can have confidence coding with? Better decisions upfront will yield another invaluable result, which is reduction of technical debt. This is even more invaluable than the first, because how do we even measure technical debt? I'm legitimately asking the question, because I want you to think more about it throughout the talk. Acceptable amount, how you combat it, etc. I hope to show that the React/Flux mindset will actually correlate to less tech debt, better maintainability, and a host of other amazing benefits.
- A good heuristic for gauging the level of simplicity is the amount of business language in the code. Does your code speak the language of the business? Or the language of the abstraction?
- So… it’s a given that simple is better, but what is the common cause of Complexity?
- Abstractions. This may seem counter-intuitive, since this is primarily what we do every day, but I’ve come up with a few heuristics around abstractions that should highlight the potential risks associated with them. I think it’s worth noting that I’m mainly referring to Black Box abstractions, or inextensible abstractions. I’m sure everyone here is familiar with The Law of Leaky Abstractions. It states that "All non-trivial abstractions, to some degree, are leaky" I like the fact that he states "non-trivial" here, because I'm not railing against the micro level, rather the macro level. Frameworks and larger libraries that are potentially abstracting the wrong things. Obviously this is very subjective, so let me define some heuristics based on my experience, and then argue with me after my talk.
- The heuristic here is that too many abstractions is generally a bad choice. I think this one is less controversial, as we’ve all heard the phrase and experienced “yet another layer of abstraction” at some point. What’s worth noting here, is that in our effort to achieve Simplicity, we must temper the level of abstraction to an appropriate level, otherwise we’re creating an intractable number of abstractions and the nasty byproduct is increased cognitive load.
- This should really say, “black box abstractions” can be limiting. If you didn’t create the abstraction, it’s likely difficult to alter or extend. You will inevitably run into the “framework doesn’t support it” scenario, and now you have to start hacking. You are crippled by the set of operations that the abstraction provides to you. Templating Engines are an easy example, because they are, in most cases, limited in the scope of their operations.
- This heuristic is derived from the first, in that it draws a line in the sand as far as “too many abstractions” goes. Effectively, you have to use your own heuristics to determine what is or isn’t worth relinquishing control of. You’re inviting risk into the project when doing so, but given enough experience, you should be able to make a sound decision. Let’s look at some candidates for good abstractions.
- Seems like a fine abstraction to me. For the most part, data persistence is worthy of abstraction as it is generally the same set of functionality, regardless of the medium. If it’s Postgres, MySQL, NOSQL, whatever, you’re probably going to have the same sets of operations across the board, so some abstraction here is fine… But even as I accept this as a worthy abstraction, it’s common to fight with your ORMs.
- Rendering is another good candidate. Similar to data fetching, the abstraction is sound in that it’s almost universally the same ideas at play, they just vary by each device’s implementation. I could probably make a good Internet Explorer joke here, but we’re on Windows 10 now, so go Spartan, Edge, whatever.
- To me, this is the line in the sand as far as the heuristic goes. Surrendering control over your Data Flow is a bad idea, at least in my experience. How data flows is the heart of your application. I posit that there’s a direct correlation between data flow needs and your client’s needs, in that both will be unique from project to project. Effectively, there is no one size fits all when it comes to data flow. I think this underlies the point of things like polyglot persistence. While you’re accepting numerous data fetching and persistence abstractions, you’re not relinquishing control over how your data arrives or flows from persistence.
- This is generally what we do as programmers. We move bits around. We try, and usually fail, to model the real world in our code. It’s generally difficult to do, but it doesn’t hurt to look to the real world for examples. Especially when our goal is to make things Simpler. Can anyone in here give me an example of two-way data binding in nature? What about unidirectional data flows? Rivers? Streams? The Water Cycle?
- You have some data, you manipulate that data, notify the presentation layer of its changes, and the User sees those changes. This is a watered down version of Smalltalk MVC, where the View observed changes directly from the Model. Of course, this was easier back then, because it was on desktop devices, not distributed across the Web. What are we really doing with client-side applications? We’re building applications in little desktop environments. Why should it be any harder than this?
- Flux and React are basically doing the same thing if we view them at the 30k foot level. Flux manages your data flow, and notifies your presentation layer, in this case, React, of changes in the model.
- I say “in this case”, because you can use the Flux pattern with anything. Angular, Ember, or vanilla JS. It’s really just letting you make decisions about how your data flow is managed.
- We get data from somewhere, remember, a data fetching abstraction is ok… And we then feed that data into our data flow. You make the decisions about how your data should be altered, and how that data will make its way to the presentation layer. You should always own this code, and it should be simple to reason about. If you own your data flow, and understand it at all times, it’s less likely that you’ll introduce bugs or run into “the framework doesn’t support it” scenarios.
- So, let’s take a quick look at the Flux pattern before we dive into the code.
- To tie the pattern together, we need to introduce Actions Actions are just Commands Typically, they are explicitly named (again, think DDD, Ubiquitous Language, declarative and well named functions) During the execution of the command, calls may be made to Web APIs via AJAX, or simply pass some data along to a Store The Action’s type will be picked up by Stores that care to respond to it, and the Store can respond to the changes associated with that Action, and potentially (usually) emit that some data changed
- The core concepts at play here are unidirectional data flow (in both Flux and React) Where mutations are triggered by semantic/declaratively named Actions Stores expose their data through public getters, but don’t allow you to alter it directly, this is always done through Actions and the Dispatcher. Basically, you’ve got a nice DDD/CQRS pattern for your JavaScript application. Events, Flow/Ovbserver Sync
- Alright, time for teh codez. Before I start, anyone have any questions up to this point?
- While you’re able to control the flow of your data in your application with Flux, you are surrendering the way your data flows in terms of presentation to React. Now, React still relies on unidirectional data flow, so this isn’t a painful concept to adopt. And even though you’re leaning on React as an abstraction, you’re still able to make decisions about how your data will flow through your UI in how you structure your Components. What I find more interesting here, is keeping the separation of State clear. Whether or not something belongs in a Flux Store or in a React Component is a decision left to the developer, but one worth noting. A piece of State may transition between the two based on changes in requirements or code. A quick example would be whether or not a checkbox is checked. Initially, I would call this a View concern, and leave it at that. But this can easily become an Application State concern when you need to persist the fact that the selection was made, or have that checkbox pre-selected the next time the page loads.
- Commit, Revert, Reset, Rollback Amazing development and debugging experience Highly recommend both talks