Live data from Hacker News

Things I Don’t Know as of 2018

overreacted.io

121–130 of 226 posts

Re: Things I Don’t Know as of 2018

#121
post #45

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…

I love the clean design on your website. All the best!

Re: Things I Don’t Know as of 2018

#123

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

That's one way to look at them, yes.

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

#124
post #63

Earlier 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…

Yeah, the docs can't solve everything, but I'm hoping we can improve the structure, the content, the reading flow, and how the prerequisite concepts are handled.

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:

https://redux-starter-kit.js.org/

Re: Things I Don’t Know as of 2018

#125
post #30

Earlier 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…

Per my other comment just above ( https://news.ycombinator.com/item?id=18784238 ), please try out our new `redux-starter-kit` package and see how much it simplifies things for you:

https://redux-starter-kit.js.org/

Re: Things I Don’t Know as of 2018

#126
post #70

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

You don’t think that’s a problem? I don’t think there’s any value in being a name in programming. There is certainly value in a dollar sense (to their own career prospects at least), but I don’t understand why people would be like “wow! It’s $name! They’re famous!”

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

#127
It’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 his multiple and very helpful posts, but as someone that enjoys functional languages and hopes to see a full featured ML react, or at least a full support for typescript, I really hope that Dan can see the advantages in the “functional way” given that he is now one of the main actors.

Re: Things I Don’t Know as of 2018

#128

It'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…

This is disgusting. I’m not condemning you for finding a gap in the market — that’s totally fair play. But the fact that this can exist and that we have a culture of celebrity in software development at all (especially in such a dishonest way) is just disgusting.

Re: Things I Don’t Know as of 2018

#129

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

No, tech is not easy. I dont think I’ve met a software engineer in my entire 20 year career who would characterize programming as “easy”. I don’t think of law, medicine, and architecture as easy either. I’m sure I could have been an architect, if I spent years learning it like I did programming. But that doesn’t make it easy.

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

#130

It’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…

I think you’re a bit confused here. Facebook isn’t “pushing” anything.

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.

Post reply on HN