81–90 of 338 posts
I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…
I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…
The svelte approach of implementing better paradigms using compilation rather than using abstractions just seems infinitely better, and a better way to scale up a program in general. I do wonder why this idea never caught on; I think Alan Kay was investigating building a programming platform based on this idea but that's just academic.
It's kind of funny that a NYT graphic designer (Rich Harris) outsmarted so many CS academics in finding the right software engineering tools.
How's unit testing in Svelte today? That's the main worry I have with template-based systems (well, that and TypeScript support, but I hear that that's quite OK now).
0: https://testing-library.com/docs/svelte-testing-library/intr...
Is it necessary to use a worker for the timer? If you just record the start time, then inconsistent setTimeout calls aren't a problem because each call calculates the duration from start time to current time. Or am I missing something?
I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…
How is Svelte "just JavaScript" when it uses custom templates and file types?
> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local st…
Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much…
If you get a chance, I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to show both how Redux works and show our recommended practices:
- "Redux Essentials" tutorial [0]: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit
- "Redux Fundamentals" tutorial [1]: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns
The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.
You should also read through the Redux "Style Guide" docs page [2], which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps.
Finally, we've got an upcoming "RTK Query" API that we're finalizing and adding to Redux Toolkit (inspired by tools like React Query and Apollo) , which should drastically simplify the data fetching story for Redux apps.
[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...
[1] https://redux.js.org/tutorials/fundamentals/part-1-overview
Earlier quoted context omitted.
Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much…
I also don't like having all those constants like LOADING_PRODUCTS ... And I don't have them, instead this is how you create a type safes actions with typesafe-actions package. export const signIn = { request: createAction("auth/signin/request")(), success: createAction("auth/signin/success") (), error: createAction("auth/signin/error") (), }; getType is a function from typesafe-actions as well. Not trying to sell yo…
I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…
Have you ever worked on very large React applications without Redux or Saga? I just cannot imagine any other way of keeping my application sort of understandable.
Earlier quoted context omitted.
I'm not sure I agree with your framing of the precise terminology ("passing a reference to an object, by value" vs "passing an object by reference"), but it also isn't important. What's important is this: let a = { foo: "bar" } let b = { foo: "bar" } console.log(a === b) // false and this: let a = { foo: "bar" } let b = a b.foo = "blah" console.log(a.foo) // "blah" This is the kind of misunderstanding that causes ins…
This is the kind of misunderstanding that causes insidious bugs. That's how all mainstream languages with a GC work, Java, C#, Ruby and Python, it's not particular to JS. And this why why languages like Clojure are nice to work with. but it also isn't important It's important if you really want to know why your examples work they way they do.