7 ms·

Firebase as a React Hook

126 points by dsaffy 7y ago

tracker1 7y ago
Cool, I would suggest supporting it as a template string processor, that way you can escapee (encodeURIComponent) the key values passed in more easily. const value = useDbDatam`/sometype/#{someId}/foo`;
pininja 7y ago
Looks good! I’m going to try it out on a project. Do you have any ideas for hook designs to write/update firebase data?
- dsaffy 7y ago
  We don't use hooks for doing writes / updates... I'm curious if there's a clever way to do that. Maybe the useDbData hook could also return a write callback?
sjroot 7y ago
See also: React Firebase Hooks https://www.npmjs.com/package/react-firebase-hooks https://www.npmjs.com/package/react-firebase-hooks
- jeffgreco 7y ago
  I've been using a lot of this library with Firestore and it's great.
julbaxter 7y ago
Does someone know an equivalent for Firestore?
- jeffgreco 7y ago
  React Firebase Hooks (mentioned elsewhere in the thread) works great with Firestore: https://www.npmjs.com/package/react-firebase-hooks https://www.npmjs.com/package/react-firebase-hooks
- deleted 7y ago
  [deleted]
ng12 7y ago
This is the kind of stuff that makes me really love hooks. I've been able to refactor so much code cleanly -- complicated data fetching logic, ugly parts of my Redux store, confusing HOCs, window.setInterval spaghetti, etc. Really excited to see more high-level hooks get published.
- dsaffy 7y ago
  Yes! I’ve replaced so many HOCs... hooks are so much cleaner.
- neals 7y ago
  I tend to be "behind" on the latest and greatest in my frontend Dev work. Usually picking stuff up 1 or 2 years after the initial hype. I do have to say that I am eyeballing hooks for solving HOCs, which have been popping up more and more in my applications.
  - davnicwil 7y ago
    This is a great strategy in many ways, because after a couple of years the 'this solves every problem' hype has mostly settled and the good, practical uses for the newer pattern are usually fairly clear from consensus. I'd say use this to your advantage with hooks. They're amazing and much nicer for some things, but don't go in thinking of HOCs, render props, even class components with lifecycle methods, as something that should be replaced entirely because hooks are universally better at everything they can do. The latter are indeed cleaner than hooks, simpler, less hassle, etc in many situations - and truly, honestly, a lot of the time it's nothing more than personal preference anyway.
    - ng12 7y ago
      I find that most the most common situation where a class component seems simpler is because the component is broken -- e.g. someone took a shortcut and assumed a prop would never change, made assumptions about the comparisons needed in `componentDidUpdate`, or didn't handle race conditions. Personally I'm at the point were I think hooks have been vetted enough that I'm comfortably recommending functional components in all situations. I teach a short "Intro to React" workshop and at this point I don't even mention class components except for a very brief FYI at the end, and even that is mostly in case developers encounter class components in Stack Overflow.
evolveyourmind 7y ago
I think you have a typo in the second code example: let students = useDbDatum(`classes/${classUid}/students`); let uids = Object.keys(students || {}); let paths = studentIds.map(id => `students/${id}/name`); studentIds on line 3 should probably be uids
- dsaffy 7y ago
  Yup... fixed!
danappelxx 7y ago
In one of the examples, the author fetches results from Firebase, and then sorts them in the browser. I'm not huge on Firebase, but aren't there methods ([0]) to do this on the database, where it'd be much faster and wouldn't waste client cpu? If this is the case, then this is a bit of faulty abstraction - your database queries are going to be more than just 'select * from <>'. I'm sure there's a way to accomplish this with react hooks without sacrificing elegance for performance. [0]: https://firebase.google.com/docs/reference/js/firebase.database.Reference.html#orderbyvalue https://firebase.google.com/docs/reference/js/firebase.datab...
- dsaffy 7y ago
  You are correct - Firebase can order server-side. I also believe I could integrate it without sacrificing elegance. At some point I'll put out a new version that takes advantage of this.
  - danappelxx 7y ago
    Looking forward to it :)
- SkyPuncher 7y ago
  Some of this comes down to cost optimization. I believe Firebase charges per record returned. Having an index and sort query doubles the costs compared to client side sorting on the index.
  - danappelxx 7y ago
    But at the same time, what if you want to filter records? Doing it on the Firebase side saves both time and money.
    - deleted 7y ago
      [deleted]
  - socceroos 7y ago
nicoburns 7y ago
I'd highly recommend people to stay away from Firebase. The querying options are really lacking. You'll likely get much better performance for much cheaper, and easier to develop for with a cheap postgres instance.
- jeffgreco 7y ago
  It's a case of using the right tool for the right job. It is indeed lacking for complex queries, and those use cases should probably stick with SQL. I've been surprised over five years of using Firebase how often complex queries weren't necessary, though! I highly recommend using Firebase if you want realtime data synchronization and great client libraries as well as easy auth and some nice integrations with cloud functions and the like.
- friedman23 7y ago
  I don't mind using SQL (and I would actually prefer it) but what I want to avoid is having to build an api middleware with auth for my personal projects. Are there any alternatives to firebase you would recommend that would allow me to use SQL without having to build out an API?
  - crench 7y ago
    PostgREST does this fairly well.
  - elitan 7y ago
    I was in the exact same position as you one year ago. Then I found Hasura (https://hasura.io https://hasura.io) and built Nhost (https://nhost.io https://nhost.io). While building Nhost I always had Google Firebase in mind regarding how good they are for the developer experience.
  - kiwicopple 7y ago
    I went through the exercise of replaceing our Firebase with Postgres last year. In the process I built a middleware abstraction that I am opensourcing now : https://supabase.io https://supabase.io As a bonus it even has real-time functionality
jcampbell1 7y ago
Is this bit of code considered kosher javascript? {[path]: payload} I don't think I have seen this before... it looks like a short cut to get a dynamic key. I can't decide whether I like it or hate it. It is new to me, and it seems like typescript won't understand it. You will also have a bad time if path === 'constructor'.
- wrkronmiller 7y ago
  Yes, it creates an object with key as the value of path and value the value of payload. If path=1, payload=2, this call would make the object {‘1’: 2 }
  - jcampbell1 7y ago
    That is what I thought, and if path = ['foo','bar'] and payload = 2, it makes {'foo,bar',2}. It is for sure making max use of dynamic programming. Typescript accepts it as {[path as any]: payload} which is pulling ejection lever on typescript. Glad I learned something new from this.
    - PudgePacket 7y ago
      It's just a nice quality of life improvement compared to const obj = {}; obj[foo] = 10;
kevindetry 7y ago
There is also Google's own library for that: https://github.com/FirebaseExtended/reactfire https://github.com/FirebaseExtended/reactfire

126 points by dsaffy 7y ago

Cool, I would suggest supporting it as a template string processor, that way you can escapee (encodeURIComponent) the key values passed in more easily. const value = useDbDatam`/sometype/#{someId}/foo`;

pininja 7y ago

Looks good! I’m going to try it out on a project. Do you have any ideas for hook designs to write/update firebase data?

dsaffy 7y ago
We don't use hooks for doing writes / updates... I'm curious if there's a clever way to do that. Maybe the useDbData hook could also return a write callback?

sjroot 7y ago

See also: React Firebase Hooks https://www.npmjs.com/package/react-firebase-hooks https://www.npmjs.com/package/react-firebase-hooks

jeffgreco 7y ago
I've been using a lot of this library with Firestore and it's great.

julbaxter 7y ago

Does someone know an equivalent for Firestore?

jeffgreco 7y ago
React Firebase Hooks (mentioned elsewhere in the thread) works great with Firestore: https://www.npmjs.com/package/react-firebase-hooks https://www.npmjs.com/package/react-firebase-hooks
deleted 7y ago
[deleted]

ng12 7y ago

This is the kind of stuff that makes me really love hooks. I've been able to refactor so much code cleanly -- complicated data fetching logic, ugly parts of my Redux store, confusing HOCs, window.setInterval spaghetti, etc. Really excited to see more high-level hooks get published.

dsaffy 7y ago
Yes! I’ve replaced so many HOCs... hooks are so much cleaner.
neals 7y ago
I tend to be "behind" on the latest and greatest in my frontend Dev work. Usually picking stuff up 1 or 2 years after the initial hype. I do have to say that I am eyeballing hooks for solving HOCs, which have been popping up more and more in my applications.
- davnicwil 7y ago
  This is a great strategy in many ways, because after a couple of years the 'this solves every problem' hype has mostly settled and the good, practical uses for the newer pattern are usually fairly clear from consensus. I'd say use this to your advantage with hooks. They're amazing and much nicer for some things, but don't go in thinking of HOCs, render props, even class components with lifecycle methods, as something that should be replaced entirely because hooks are universally better at everything they can do. The latter are indeed cleaner than hooks, simpler, less hassle, etc in many situations - and truly, honestly, a lot of the time it's nothing more than personal preference anyway.
  - ng12 7y ago
    I find that most the most common situation where a class component seems simpler is because the component is broken -- e.g. someone took a shortcut and assumed a prop would never change, made assumptions about the comparisons needed in `componentDidUpdate`, or didn't handle race conditions. Personally I'm at the point were I think hooks have been vetted enough that I'm comfortably recommending functional components in all situations. I teach a short "Intro to React" workshop and at this point I don't even mention class components except for a very brief FYI at the end, and even that is mostly in case developers encounter class components in Stack Overflow.

evolveyourmind 7y ago

I think you have a typo in the second code example: let students = useDbDatum(`classes/${classUid}/students`); let uids = Object.keys(students || {}); let paths = studentIds.map(id => `students/${id}/name`); studentIds on line 3 should probably be uids

dsaffy 7y ago
Yup... fixed!

danappelxx 7y ago

In one of the examples, the author fetches results from Firebase, and then sorts them in the browser. I'm not huge on Firebase, but aren't there methods ([0]) to do this on the database, where it'd be much faster and wouldn't waste client cpu? If this is the case, then this is a bit of faulty abstraction - your database queries are going to be more than just 'select * from <>'. I'm sure there's a way to accomplish this with react hooks without sacrificing elegance for performance. [0]: https://firebase.google.com/docs/reference/js/firebase.database.Reference.html#orderbyvalue https://firebase.google.com/docs/reference/js/firebase.datab...

dsaffy 7y ago
You are correct - Firebase can order server-side. I also believe I could integrate it without sacrificing elegance. At some point I'll put out a new version that takes advantage of this.
- danappelxx 7y ago
  Looking forward to it :)
SkyPuncher 7y ago
Some of this comes down to cost optimization. I believe Firebase charges per record returned. Having an index and sort query doubles the costs compared to client side sorting on the index.
- danappelxx 7y ago
  But at the same time, what if you want to filter records? Doing it on the Firebase side saves both time and money.
  - deleted 7y ago
    [deleted]
- socceroos 7y ago

nicoburns 7y ago

I'd highly recommend people to stay away from Firebase. The querying options are really lacking. You'll likely get much better performance for much cheaper, and easier to develop for with a cheap postgres instance.

jeffgreco 7y ago
It's a case of using the right tool for the right job. It is indeed lacking for complex queries, and those use cases should probably stick with SQL. I've been surprised over five years of using Firebase how often complex queries weren't necessary, though! I highly recommend using Firebase if you want realtime data synchronization and great client libraries as well as easy auth and some nice integrations with cloud functions and the like.
friedman23 7y ago
I don't mind using SQL (and I would actually prefer it) but what I want to avoid is having to build an api middleware with auth for my personal projects. Are there any alternatives to firebase you would recommend that would allow me to use SQL without having to build out an API?
- crench 7y ago
  PostgREST does this fairly well.
- elitan 7y ago
  I was in the exact same position as you one year ago. Then I found Hasura (https://hasura.io https://hasura.io) and built Nhost (https://nhost.io https://nhost.io). While building Nhost I always had Google Firebase in mind regarding how good they are for the developer experience.
- kiwicopple 7y ago
  I went through the exercise of replaceing our Firebase with Postgres last year. In the process I built a middleware abstraction that I am opensourcing now : https://supabase.io https://supabase.io As a bonus it even has real-time functionality

jcampbell1 7y ago

Is this bit of code considered kosher javascript? {[path]: payload} I don't think I have seen this before... it looks like a short cut to get a dynamic key. I can't decide whether I like it or hate it. It is new to me, and it seems like typescript won't understand it. You will also have a bad time if path === 'constructor'.

wrkronmiller 7y ago
Yes, it creates an object with key as the value of path and value the value of payload. If path=1, payload=2, this call would make the object {‘1’: 2 }
- jcampbell1 7y ago
  That is what I thought, and if path = ['foo','bar'] and payload = 2, it makes {'foo,bar',2}. It is for sure making max use of dynamic programming. Typescript accepts it as {[path as any]: payload} which is pulling ejection lever on typescript. Glad I learned something new from this.
  - PudgePacket 7y ago
    It's just a nice quality of life improvement compared to const obj = {}; obj[foo] = 10;

kevindetry 7y ago

There is also Google's own library for that: https://github.com/FirebaseExtended/reactfire https://github.com/FirebaseExtended/reactfire