[HN Gopher] Firebase as a React Hook
___________________________________________________________________
Firebase as a React Hook
Author : dsaffy
Score : 64 points
Date : 2020-01-15 17:59 UTC (5 hours ago)
(HTM) web link (pragli.com)
(TXT) w3m dump (pragli.com)
| evolveyourmind wrote:
| 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 wrote:
| Yup... fixed!
| danappelxx wrote:
| 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.datab...
| SkyPuncher wrote:
| 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 wrote:
| But at the same time, what if you want to filter records?
| Doing it on the Firebase side saves both time and money.
| dsaffy wrote:
| 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 wrote:
| Looking forward to it :)
| pininja wrote:
| 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 wrote:
| 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?
| ng12 wrote:
| 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.
| neals wrote:
| 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.
| dsaffy wrote:
| Yes! I've replaced so many HOCs... hooks are so much cleaner.
| sjroot wrote:
| See also: React Firebase Hooks
|
| https://www.npmjs.com/package/react-firebase-hooks
| jeffgreco wrote:
| I've been using a lot of this library with Firestore and it's
| great.
| julbaxter wrote:
| Does someone know an equivalent for Firestore?
| jeffgreco wrote:
| React Firebase Hooks (mentioned elsewhere in the thread) works
| great with Firestore: https://www.npmjs.com/package/react-
| firebase-hooks
| [deleted]
| tracker1 wrote:
| 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`;
| nicoburns wrote:
| 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.
| friedman23 wrote:
| 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?
| elitan wrote:
| I was in the exact same position as you one year ago. Then I
| found Hasura (https://hasura.io) and built Nhost
| (https://nhost.io). While building Nhost I always had Google
| Firebase in mind regarding how good they are for the
| developer experience.
| crench wrote:
| PostgREST does this fairly well.
| kiwicopple wrote:
| 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
|
| As a bonus it even has real-time functionality
| jeffgreco wrote:
| 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.
| dsaffy wrote:
| FWIW it's worked well for us, but our application has the
| follow characteristics: 1) Our data is relatively small and
| well-scoped, so we're only querying small amounts of data
| (maybe 10-20 queries each of <50 records) from any individual
| client 2) We care a lot about real-time, so we want data
| manipulation on one client to show up pretty immediately on the
| other 3) While we'd definitely save money switching to a
| Postgres instance, we're not spending that much to begin with
| on Firebase.
|
| I think these play well to Firebase's strength. In a previous
| life I built an app that sucks in a lot of data exhaust and
| then visualizes it... IMO Firebase wouldn't have worked well
| for that.
___________________________________________________________________
(page generated 2020-01-15 23:01 UTC)