11–20 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?
I recently rewrote a small UI from Preact to Svelte and while it was certainly a learning experience, I have to say working with Svelte is fantastic. My only complaint is that the Typescript support isn't quite perfect yet, but it's already very functional.
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?
I've always wanted to try Auth0 and I've heard great things! I would love to hear if anyone has had a positive experience with Auth0 as well.
> I love Firebase Authentication, it's such an easy way to add auth to side projects. It's easy to use but it adds 55kB gzip to your project. https://bundlephobia.com/result?p=@firebase/auth@0.16.4 A couple of comments on the Svelte code. 1) It doesn't makes much sense to use onMount() with listenForAuthChanges(). Just modify the currentUser writable whenever onAuthStateChanged() has an update. Now simply import and…
Re 1) Where should you put the code to initialize the SDK? Code that ideally should only be ran once in the entire lifecycle of the page. For Firebase, will ES modules help with code splitting? The new Svelte kit framework is built by Vite (runs on ES build underneath).
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?
I've always wanted to try Auth0 and I've heard great things! I would love to hear if anyone has had a positive experience with Auth0 as well.
They have recently been bought out by Okta... Which by some accounts might not be a good move.
I no longer use React in my projects and only use Svelte and it feels great. I'm very happy with it.
Javascript n00b question... is there any difference between onMount(() => { return listenForAuthChanges() }) and onMount(() => listenForAuthChanges()) ?
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.
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 state (useState)
Then using Controller pattern, within the controller I use 4 types of hooks, 1 navigation (useHistory), 2 read global state (useSelector), 3 dispatch an action (useDispatch), 4 useEffect() to execute on props change or component mount.
That's it, that's where the realm of React and UI ends for me, everything else is in Ducks, Ducks are single file or folder per module that contains Actions, Epics (Obervables) or Sagas (generators), Reducers, initial state of store and Typescript types.
I really like this separation of concerns:
- dumb components: to worry just about the looks and local state.
- controllers: to worry about data in, actions out, life cycle and navigation.
- Ducks: Management of data fetching and global state.
I wrote this from the top of my head, but if anyone is interested I'm thinking about writing a demo repository and document this approach, maybe others have done it already this is not new, but practices that I've been collecting along the way.
> 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…
> 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…
As an fyi for anyone not aware, there are eslint/tslint plugins for this to help avoid it.