Put together an intro for adding Firebase to a Framer prototype: http://designsprints.com/framer-screencast-firebase/
Jay Stakelon shared a great DN prototype earlier this month using Firebase to track upvotes. I wanted to highlight Firebase's realtime syncing by showing a layer's state and state switches synced across devices.
That's such a great way to teach how Firebase can be simply integrated. Awesome!
Jay - My brother Josh said he really enjoyed your workshop btw.
This is great.
haha, was just looking into integrating Firebase last night. Awesome demo!
this is really awesome and seems a bit simpler to set up than parse. I am playing with your example and I realize that there are different techniques to handle DB updates.
I created an object (fb) that holds more information and that I read/write to firebase. The plan is to have other data stored in that object so the prototype can be more complex.
Every .set actually triggers an .on 'value', which means the prototype is doing it all the same time and I imagine this can get hairy with more complex prototypes. Any technique/recommendations to handle that?
I am using a potentially large object (fb) to hold all of the database and I am reading and overwriting that on change. Is it possible to only listen to specific changes of an object and only retrieve that change?
Wow, thanks for the feedback everyone.
Johannes Eckert If I'm understanding correctly, you should be able to just create another reference by adding the child path to the URL. In the example you shared, you can just create another reference to ...firebaseio.com/state and set .on 'value' to that instead.
Something like this: http://share.framerjs.com/7ovj8jml61fh/ (very similar to yours I just added stateRef and changed fb to fbs in the .on 'value' event.
When you store an object it gets mapped to child locations. This page explains it more detail: https://www.firebase.com/docs/web/guide/saving-data.html
thank you, Ces Cortez. Creating a new database just to store a single value? I guess that's fine with the footprint of these light databases. I like the object approach better, somehow. Thanks for pointing out the links!
Johannes Eckert sorry for the confusion, it's not an entirely new database. It's just a reference to a child within the same database. When you store your "fb" object it creates "test" and "state" child locations that you can access by appending /test or /state to your URL.
You could also do stateRef = myDataRef.child("state")
Thanks for the follow up, Ces Cortez. I just played around with a few calls and realized the fact that they are just pointers. Your second link on the data stored helped, too. Amazing how simple that is. The event listeners on db changes really do blow my mind.
I am still unsure if setting the value and getting an event change in the same app (at the same time!) is good for more complex things. I could imagine an animation running twice because of the slightly delayed eventListener for the db change firing …
Great tutorial! I am just wondering how you could apply this to draggable objects?
Josh Ackerman one would had to store the object's current X and Y position in the database and apply that to the listening browsers. The only problem I see is a certain lag/bandwith problem with storing that information. Maybe some Utils.throttle helps using less bandwidth