I'd like to go even more back to the fundamentals. Hopefully finishing SICP, building a JavaScript interpreter/compiler and other fun experiments to get a better understanding of the foundation that we're building everything on top of today.
It covers the foundation of functional languages with the simply typed lambda calculus, and also the principles of formal specifications and proofs. It's suitable for self learning, but is a significant effort so you need to have a strong interest in these topics and be ok with a very formal approach to software.
This is a good read [0]. Been using this approach in several larger applications for a while (with great success).
By decoupling the selection of state from the actual state structure (using relative selectors) + defining a public interface for your features (your app will basically consist of smaller apps - fractally) you can achieve what you're after.
That's just the price of diagnostics. If you read further you'll see that the full repair price is £169 + shipping. But yes, that confused me at first as well. They replace the GPU and use lead solder.
The sad reality is there doesnt exist a reliable source of _real_ new replacement GPU chips. Almost every single chip from china is either a pull from dead laptop or old stock(1). Chinese counterfeit markings, clean them up and sell as new.
The absolute best case scenario is you get really new old stock and it will survive at least 2 years, but in reality it will most probably be a pull from recycled trash with week-month lifespan.
1- Nvidia chips were ALL factory defective (bad underfill between die and bga carrier), every single GPU at least up to FERMI has a limited life span dependent on thermal stress. Nvidia had to issue huge recall and restart manufacturing of ancient chips with fixed underfill formula - they only did a limited run for select partners (Dell, Apple) and those chips are pretty much _gone_ from the market.
At least with the AMD 67X0 models of the MBP the problem isn't the chip itself, but the solder connection (or lack thereof). Same issue as the XBOX 360 RROD. So just replacing from lead free solder to lead solder does the trick.
The 17" MBP is such a beautiful and usable machine. I've been using a rMBP from 2012 until recently, but when Apple announced the new 2016 MBP I went and got a mint maxed out late 2011 17" instead. Just to give it a try really. I now love everything about it (especially the keyboard and the screen). Serviceability and the fact that you can run a 4TB RAID 0 or a 2TB RAID 1 is a huge bonus as well.
Regardless of the justifications Apple may have to continue on their current path, it personally (and very subjectively) makes me sad. They used to be a tent pole in my digital life, but now I feel we've lost touch with each other...
Redux can come off as a bit intimidating, but fortunately builds entirely on old ideas and concepts like publish/subscribe, reduce/fold and pure functions that takes a value + an event and returns a new value (reducer function).
Without the middleware support Redux pretty much boils down to this:
function createStore(reducer) {
let state = undefined;
let subscribers = [];
return {
getState() {
return state;
},
subscribe(subscriber) {
subscribers.push(subscriber);
},
dispatch(action) {
state = reducer(state, action);
subscribers.forEach(subscriber => subscriber());
}
};
}
The advantage of Redux will start to show itself first when your app grows larger and you start doing things like consuming many different views/derivatives of the same state (using selectors) spread across your application.
Redux (core) doesn't actually solve the other big complexity culprit of big web applications though - asynchronous flow and side effects. For that you'll have to look into middlewares like redux-thunk or redux-saga, depending on your needs.
I'd suggest that instead of focusing on specific implementations such as Redux it's a good idea to take a look at those concepts + patterns like CQRS to get an understanding of why you'd want these things in the first place.
It's usually a good idea to feel the pain it alleviates before diving in at the deep end.
I get the feeling that the terms "easy" and "simple" are being mixed up here. MobX is a lot more complex than Redux (core), as it tries to do a lot more things that are braided together as a package. In Redux you choose to bring in that complexity (reselect, redux-saga, etc) if necessary. "Easy" is subjective, "simple" is not.
> MobX is a lot more complex than Redux (core) [...] In Redux you choose to bring in that complexity (reselect, redux-saga, etc) if necessary.
I've dug quite a bit into Redux and I don't think that's really true. In particular I don't think you "choose" to bring in that complexity. Redux is inherently complex the moment you add async actions to it, which (in my view) any real Redux app will need. Something as simple as "fetching some data when you click a button" is a surprisingly elaborate process. Similarly, trying to map a large state tree (which any real Redux app will have) to a component tree is not easy. Libraries like reselect and redux-saga (or event redux-thunk) sprung up and became essentially universal because they address the inherent complexity of Redux.
I just don't think it makes sense to tease out a small chunk of the code a Redux app needs to function and say "look, this chunk is small!"; it's true but meaningless.
MobX is dead simple, it's a short write and here's how it works:
- observables: add a getter/setter pair in place of the property - when it gets modified emit an event.
- observer: when an observable getter gets called inside the `render` in React - listen to future updates and re-render.
- computed: do the same thing as observer - but emit the value instead of rendering.
All MobX does is change detection, it has a very low API surface, it can be implement in a lot less code (but optimizes heavily) and it is one of the simplest packages I worked with without middlewares and connectors and selectors and so on.
In Redux you have a dispatcher, actions, a reducer and so on. In MobX you just have plain JavaScript objects for state and plain functions. MobX also composes much better with things like Rx.
Except it is. I have worked on a couple of react/redux production projects and they all work well, but I still think redux is way too convoluted for most use cases. Too many abstract concepts.
Also their naming of the features could have been better. For example "reducer" makes sense ONLY after you understand what's going on. It should be the other way around--the naming should be intuitive enough to actually help me understand the concept easier.
A lot of physics theories are distilled down to a single equation, but that doesn't mean it's simple concept to understand. I personally think a library with 10000 lines of code that operate using setters and getters is much more simple to understand than a library with 100 lines of code that has all these esoteric concepts.
It looked "magical" and tripped up my "too good to be true and I'll have problems later" sensor. Then I looked at that video and realised the idea is rather simple and brilliant.
Take a step back and focus on JavaScript the language. Really learn how things work. Then take a step even further back. Learn more about data structures, about abstractions and how to think declaratively vs. imperatively. Rinse and repeat for the rest of the stack.
That way you'll have a solid foundation to build on top of. At some point you'll start to see patterns, and that all the "new" things are just incrementally improved materializations of patterns and concepts that have existed since way before the web was even thought of.
Spend most of your learning/experimenting time on fundamentals (timeless). Learn actual implementations and specifics when you need to, just in time. Avoid learning specifics (lib/fw) just in case.
Source: My own personal experience + the very insightful experience of teaching classes in JavaScript and React the last two years.
Take a step back and focus on JavaScript the language. Really learn how things work. Then take a step even further back. Learn more about data structures, about abstractions and how to think declaratively vs. imperatively. Rinse and repeat for the rest of the stack.
That way you'll have a solid foundation to build on top of. At some point you'll start to see patterns, and that all the "new" things are just incrementally improved materializations of patterns and concepts that have existed since way before the web was even thought of.
Spend most of your learning/experimenting time on fundamentals (timeless). Learn actual implementations and specifics when you need to, just in time. Avoid learning specifics (lib/fw) just in case.
Source: My own personal experience + the very insightful experience of teaching classes in JavaScript and React the last two years.
