This is an awesome article! I like the idea of being more forthcoming with what we don't know. > Containers. I have no idea about how to use Docker or Kubernetes. (Are those related?) I have a vague idea that they let me spin up a separate VM in a predictable way. Sounds cool but I haven’t tried it. > Deployment and devops. I can manage to send some files over FTP or kill some processes but that’s the limit of my dev…
Things I Don’t Know as of 2018
121–130 of 226 posts
Re: Things I Don’t Know as of 2018
#122I still don't know that what is love? baby don't hurt me
Re: Things I Don’t Know as of 2018
#123Earlier quoted context omitted.
There is a core issue with UI development that makes things harder and less elegant than the backend. It's the io loop. Components must change state and react to state. This where the complexity arises. If you remove the loop by having components only react to state, you will find your programs to be simple, modular and more beautiful. The feedback loop of IO destroys the functional and modular nature of UI. Function…
> Global event emitters might be the best way. I'm not sure if redux does this. I think Redux actions are essentially emitted global events.
Redux's `store.subscribe()` function is obviously a general event emitter, where the only event is "an action was dispatched", so it doesn't even need a name.
On the actions side, Redux really only has a single "root reducer" function. Since having a gigantic monolithic function for all state updates would be unmaintainable, we split that function up into smaller functions, like any other piece of code.
Since Redux was based on the existing "Flux" concepts, the idea of having multiple "stores" for each different type of data was translated into having multiple "slice reducers", each one responsible for independently updating the data at a given key in your state object. Redux provides a `combineReducers` utility for this use case, which iterates through all the keys in the state object and calls the slice reducer at each key.
If you squint at this reducer setup the right way, you can see it as being a limited pubsub event system as well.
So, it's reasonable to view a Redux store as being a 2-way pubsub system. Different parts of the app dispatch an action to "publish" an event to the mostly-independent slice reducer functions, and the store publishes a single event to let any part of the UI know that the state _may_ have been updated.
Re: Things I Don’t Know as of 2018
#124Earlier quoted context omitted.
Hi, I'm a Redux maintainer. Anything specific that confused you? Which tutorials were you looking at? We're currently planning a revamp of the Redux docs. I'd really appreciate any feedback on what things caused problems, so we can know how to make the docs better. Feel free to comment here, or ping me on Twitter or in the Reactiflux chat channels. I've also got a survey open asking for suggestions on docs structurin…
[not OP but I can remember feeling the same, also I haven't done a big redux project in about a year] I haven't looked at the docs in a while but I'm not sure that's where the big problem lies. The hard thing about Redux is that you need to "get" the core concepts (not that complex), and how they interplay with how (and when) React renders component subtrees (very complex - this requires a new understanding of react…
As part of that, I definitely want to have new category sections on "Using Redux with a UI" (which would include both how that works in general, and specific pages for use with React, Angular, Vue, Ember, etc), and "Real World Usage" (which could cover things like app structure, code splitting, choosing a side effects approach, and so on).
As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're thinking of when you say that?
FWIW, we have a new package called `redux-starter-kit`, which is specifically intended to help simplify several common Redux use cases. It includes utilities that help with store setup, reducer definitions, immutable update logic, and even creating entire "slices" of state automatically without having to write any action types or action creators yourself. I'd encourage everyone to try it out, and let us know how much it helps improve your apps and what else ought to be included:
Re: Things I Don’t Know as of 2018
#125Earlier quoted context omitted.
I will admit I am a terrible programmer, but I will say using Redux scared me away from using React at first. Maybe my React needs are minimal, but I tried following a tutorial using React and Redux and I was immensely confused. Once I struck out on my own and ditched Redux for just straight React, everything became so much clearer and simpler.
Redux, IMO is a beautiful state management library. Were you following Dan’s tutorial on Redux? Because that is a beautifully made tutorial as well. ( https://egghead.io/redux ) If you have tried to build a substantially big app with React alone, you will find yourself lost in passing down the props and callbacks and hoisting variables and what not. You definitely need a state management library where you can CRUD fr…
Re: Things I Don’t Know as of 2018
#126What I miss from this article is what he does know. Not to boats, but to contrast. I know some of the things he does not know, and I'm sure he knows things I don't know. But without knowing what his expertise is, it's easy to think you know more than him.
He's one of the most prominent React core developers. The author of Redux etc. Many JavaScript and React developers (myself included) consider him a rockstar.
If someone non-junior knew no shell scripting and had no FP knowledge — or thought that JavaScript counts as FP [spoiler alert: it doesn’t] — I wouldn’t hire them.
Re: Things I Don’t Know as of 2018
#127Re: Things I Don’t Know as of 2018
#128It's on tangent but I owned an agency before and my employees under NDA wrote opensource projects for celebrity developers. It was effectively a GhostCoders for hire service. Out of them a few developers got very popular. It was a matter of luck more than anything. Anything can catch wind anytime, we just needed to keep up with the trend. One way to catch this is coding style. Since, we employed GhostCoders - style v…
Re: Things I Don’t Know as of 2018
#129Sometimes there’s an unrealistic expectation that engineers know everything, but senior engineers I’ve worked with and hired knew most of that list... at least somewhat. Yes, comfort with bash and a knowledge of how networking actually works is something I expect someone working on computer software for 10+ years to have gotten familiar with at some point . I also expect people who build libraries inspired by prior w…
It would be great if we all met each others' expectations. And yet it doesn't work that way. A step up from where you're at is to realize that tech, ANY tech, is easy. If brute-forced by rote it can be even be learnt by those without the aptitude. What IS difficult to master, is people.
Software engineers command huge salaries because it’s not easy. Just because anyone can learn anything doesn’t make everything is easy.
I don’t understand why tech celebrates amateurism and ignorance... We don’t all know everything but we shouldn’t wear our ignorance like a badge of honor either.
Re: Things I Don’t Know as of 2018
#130It’s kind of scary that Dan Abramov doesn’t know about ML languages or typescript... I hope that he is just being humble, because otherwise I wonder if it was a complete lie when Facebook said that they were pushing on ReasonML instead of react.js. I know that he was not initially involved and that the first prototype used ocaml as a primary language before falling back to JavaScript. I really appreciate Dan work and…
There’s a React team. I’m on that team. We develop React. Facebook uses it all over the place.
There’s also a Reason team. (Its creator also wrote React originally.) They work on Reason and its React bindings. Facebook uses it in some places.
We talk to the Reason team of course. But there has never been a plan to force all React users to use Reason. I don’t know where you heard that. If you like it, that’s cool. If not, that’s cool too. We’re just sharing what we use.
I’m not sure what your practical concerns are (are Reason bindings or TS typings not good enough?) but I’d like to hear them!
Of course I know “about” ML and TS. If I didn’t know about them I wouldn’t mention them. :-) I haven’t developed anything meaningful in either of them but it’s not like I’m clueless about what types are. I’ve been using C# for years.