71–80 of 338 posts
The author praises Firebase Auth for its ease-of-integration, but I'm leery of depending on Google products due to its support horror stories. Can anyone recommend good, easy-to-integrate alternatives?
We actually started with Firebase Auth (branded as Google Identity) and moved to Auth0 later for some small differences.
Also though, Auth0 was just acquired by Okta, if that matters to you.
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…
Earlier quoted context omitted.
but with objects and arrays you can only pass by reference. It's still pass by value, you are passing the reference of the object as a value.
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…
The distinction is that, if JS truly was pass-by-reference for objects, you could change what the reference was pointing to. But you can't.
I agree with you that objects/references are a stumbling block for new programmers in JS. You have to understand how these things work but there's no explicit concept of a reference, which means it can be tricky to learn.
Earlier quoted context omitted.
Yeah I've moved to this and it is working so far. Hooks manage the data and etc, UI components are almost exclusively just UI that get some props. The UI components all have an else render if for some reason they're missing something / it avoids a crash (along with other easy to see / figure out protections)
I use an HoC to wrap components in an error boundary around key points to avoid total crashes.
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…
Now Svelte, I haven't been following, but I think the creators are working in what's going to be next and even better framework[1], to your point of things in Svelte not changing as much as in React, maybe it just a matter of time. Here is the video I had in my bookmarks for a while, I still couldn't make the time to watch, so I hope my comment is not too far from reality.
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.
Earlier quoted context omitted.
but with objects and arrays you can only pass by reference. It's still pass by value, you are passing the reference of the object as a value.
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…
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.
Javascript n00b question... is there any difference between onMount(() => { return listenForAuthChanges() }) and onMount(() => listenForAuthChanges()) ?
They are the same. It's a matter of style. For that matter, you could also write: onMount(listenForAuthChanges) which is technically simpler -- you're not constructing a new anonymous function. But if you wanted to extend the code (to say, add a console.log), you'd need to do the top version, which already has the braces. It's up to your judgment of what's clearer and likely to be more maintainable.
>onMount(listenForAuthChanges)
>which is technically simpler -- you're not constructing a new anonymous function.
Not just technically simpler, it is a perf improvement over initializing an anonymous function every time onMount is called (which you have already mentioned, I just wanted to emphasize). A minor performance improvement at that, but still, small things add up. I agree with the entirety of your post, however, well-written.
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…
> Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components. This sounds very similar to the experience of using MobX. I evangelize it as an altern…
> 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…