Maybe newish coders should learn the language they are using.
And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.
Maybe newish coders should learn the language they are using.
It's not a language thing. OOP discipline is a coding thing in general.
And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.
You sound like you don't actually understand why people like Typescript, or, more specifically, static typing.
> You sound like you don't actually understand why people like Typescript, or, more specifically, static typing.
Eh, in my experience, there are two types of Typescript users: 1) those users who appreciate the safety that type systems provide when used properly, and 2) those enterprise users of the language who have mostly only coded Java and C# and who like Typescript because it lets them write Java-style code for the browser.
I know, but lately during frontend interviews I was surprised how many times I met with "I'm a developer I can do anything" type interviewers - some of them were dotnet, others were java devs and they preferred typescript, because 1. javascript is a terrible language 2. with typescript they feel right at home 3. they can use a "proper ide" (please, don't ask, I already had an argument and a rejection when I tried to ask about webstorm)
I "don't actually understand why people like Typescript", or lemonade, or skiing, or eating fish. I know why I like it, including static typing, and how I can find a balance with using its features (and not using some).
On the other hand I'm not trying to hide that I'm bitter about the mental lazyness around typescript - I had some bad experience with interviewers who praised ts (without ever bothering to learn the core principles of javascript) a bit too much for my taste (but again, this may just be dismissed as anecdotal evidence, which it is).
The article says bind as a negative point - I perefer the new non-bound class method syntax:
```
private handleClick = (event) => {}
```
By "mental lazyness" I mean that people (as in people I have met with) piss on javascript and praise typescript and in the process they never bother to learn about javascript.
I do like vue, react, angular of course, but I don't think that you become a frontend developer from one day to the next and keep saying that typescript is _exactly_ like java (or dotnet).
According to the article yes, the issue is "what is a class":
"You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers." etc.
Eh, even in the same paragraph it says "The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers."
Also, bits of class issues show up in the other complaints.
So, no, it's not just "what is a class" and it's a weird hill to die on. I feel like most of these responses to hooks in general just focus on the most trivial detail aka bikeshedding.
I'm focusing on classes, because it seems to me that to "React" classes are a necessary evil (or they are treating them like they were).
Hooks, suspense, context wormholes - I'm not sure if these features should be part of a view engine. React, to me, did one thing and did it well, but now... I don't know.
Can't argue with the text of the article. I do, however, stand by why _I_ have found that classes are a bad match for this need, and watching the video of the demo did a much better job of suggesting the benefits and reasoning...reasons that don't really match the parts of the article you've quoted.
I worked last time on a large scale project with full waterfall and heck, it was good. I knew what to do, when to do it, team lead had great domain knowledge and was a nice guy etc.
Then the company decided that products are not built fast enough, so we should be "agile". Guess we all know the rest of the story.
Thanks! Comments like yours are what keeps me motivated to continue contributing to open source software.
But although the title is somewhat click-bait, I still think this counts as a vulnerability in my project, since there is a possible combination of default Apache setting and default project files that is exploitable.
Heavens, I thought the fire was an allegory or a worst case scenario. Looking at the artsy enterior I feel an existential dread thinking about being trapped in that place with flames around.
Well, typescript is nice. But. The amount of boilerplate I write with redux is downright annoying, add typescript to the mix and the interfaces, typedefinitions, enums, various scattered exports, actioncreators and typehelpers are just mind-boggling - I don't like it.
Heck, I already have huge livetemplates in my ide to generate most of these stuff, but it feels wrong. And while we have fun writing "enterprise quality code", routing falls apart, load indicators are missing, form validators are a mess, error handling is broken, etc.
We're currently working on a package called `redux-starter-kit` that contains some utilities to help simplify common concerns about Redux, including store setup, generating action creators, and writing reducer logic and immutable updates:
I'd appreciate it if you could take a look, try it out, and give us some feedback.
It's currently JS-only, but we're planning to convert it to be written in TS in the near future.
As for as Redux and TS in general... I know I've seen comments similar to yours ("duplicating action constants and enums", etc). Unfortunately, I don't use TS myself, and don't know enough to offer meaningful suggestions there.
If you've got specific pain points with Redux and TS, please go ahead and file an issue for discussion, and perhaps we can work on some solutions.
I recently started looking at mobx-state-tree[1] and I feel like it solves a lot of the boilerplate needed with redux in a very nice opinionated way. In particular it has built in support for tracking action history (as list of patches and snapshot), building views of computed values (selectors), organizing async action flows, and colocating all of this logic in a single model class.
It can be used on top of redux but it won't really look like redux code anymore. But since you're using immer in the starter, it wasn't going to look like redux anyway (e.g., ton of triple dots everywhere).
Do you have any opinion on mobx-state-tree? Maybe you should just bless mobx-state-tree in the starter too? (immer is built by the same mobx guy)
(I have not actually use the library yet. Secretly hoping you'll will tell me about all the cons so I don't have to do the research myself. Currently choosing a library based on which has the best saga-like support)
mobx-state-tree (mst) is an addition to mobx. While mobx is a rather generic approach to manage state via composable observables and actions, mst is a strongly opinionated enhancement of it that brings in e.g. strong typing and some simplifications.
While mst was great for some simple things, it soon runs into issues at complex requirements, one of them being performance. In my scenarios after running into some of these issues, I then rebuilt everything in mobx and brought in the strong typing etc. via TypeScript and code governance. This worked great so far, not much boilerplate, great state/action componentisation, also a great serialization/deserialization out of the box with serializr.
Hi, I've not actually used redux at any scale but I have used react a lot (sounds silly?).
I was wondering, would it be possible to have something like a strict subset of redux with minimal boilerplate and very few and very simple API functions which are redux compatible. But which can eventually be swapped with the full Redux library if need be?
No, not really. Redux itself _is_ already small - if you strip out the safety checks, it's less than 100 lines [0], and you can see the core concept in less than 25 [1].
Part of the issue is that people use the word "boilerplate" to refer to many different things, such as writing action creator functions, writing immutable update logic, calling `connect()` to generate wrapper components that talk to the Redux store, etc. Everyone seems to have a different thing that they are concerned about.
The "starter kit" package I linked tries to address several of the most common concerns, while still keeping Redux the way it's meant to be used.
You can already use Redux with any UI layer or framework, whether it be React, Angular, Vue, jQuery, or vanilla JS.
The starter kit package just provides some additional utilities for common use cases. You could use it in a TS app already, you'd just have to stub out the type declarations yourself. Reworking the package to be written in TS is mostly to allow easier integration with users building their apps in TS.
I would just love to work with mobx, coming from vue, the project is already big enough and a rewrite is not an option in this stage. Are people using redux and mobx together?
You could try the https://github.com/Hotell/rex-tils package. I find these action creator utilities make typing the redux concepts a little easier.
Also, I am working on a library which aims to centralize all of the redux constructs into reusable modules. It doesn't eliminate all if the boilerplate, but I think it makes it easier to add things to the store.
https://redux-dynamic-modules.js.org
Check out ReasonML with reason-react. Immutability, reducers and type inference built in. Way less code to write and strong guarantees by the compiler.
That' true. But wherever I look, projects and people bought into this idea that if it's good enough for Facebook (or Google in the case of Angular) then going with react+redux is a future-proof idea.
I still think that facebook can be tremendously useful, even if I unfollowed everyone and have zero posts (mostly to see events, access facebook-homepages, let people find my email address or just occasionally tell someone to send me an email instead of writing on messenger) - but heck, this latest breach is a bit too much to swallow.
And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.