Introducing Resourcerer: Declarative React Data-Fetching for REST APIsOctober 17, 2019 2:30 pm
We are excited to announce the public release of a package we’ve been using internally at Sift to handle our […]
Browser DGAF (that you use React) Pt. 2: FLIPping in ReactSeptember 21, 2016 8:05 pm
In the first post in this series, we looked at how coding within the React paradigm could lead to poor […]
Browser DGAF (that you use React)March 16, 2016 5:58 pm
Adventures in React Performance DebuggingRecently I read Benchling’s 2-part series in debugging performance issues in React, and it really echoed the issues and solutions that I’ve been working through on the Sift Science Console. So I was inspired to chime in with some of my own React performance debugging experiences in what may become a short series itself.
How We Rebuilt Our App, Part 2: From Rails + Marionette to ReactJune 9, 2015 6:32 pm
In the first post of this series, we gave an overview of Sift Science’s architectural migration to React and Dropwizard. We followed up with some best practices for scaling React in a production setting and some tips on using React with D3. Today’s post will chronicle the front-end migration process of moving from Rails + Backbone + Marionette + Handlebars to a static Backbone + React console, and the challenges we encountered.
d-Threeact: How the Sift Science Console Team Made d3 and React the Best of FriendsMay 19, 2015 10:25 pm
A little less than a year ago, the Sift Science Console Team decided to migrate its Backbone and Marionette Views to ReactJS see also our post on specific React tips we learned along the way. Among the many facets of a piece-by-piece migration like this was figuring out how best to manage (err...'reactify') our d3 charts. There were already a couple good reads/ listens on this topic—with very different views on the responsibilities of each library—which we found quite helpful in establishing our own approach.
Best practices for building large React applicationsMay 7, 2015 5:41 pm
Sift Science has been using React in production for almost a year now. In that time, we grew our application from a Backbone + React frankenstein hybrid app into one fairly large hierarchy of React components. In this post, we’ll describe some techniques and best practices that have helped us scale our UI code base with minimal friction. We’ll also walk through some common component design patterns.Hopefully this post will save you time and sanity and provide you with some new tools for maintaining a React code base that builds on itself (instead of breaking down) as the complexity of the UI grows.
How we rebuilt our app on React and Dropwizard, Part 1April 28, 2015 8:06 pm
Two years ago, we publicly launched our first fraud product with the goal of making it easy for anybody to leverage the same machine learning technology that protects the largest internet retailers. That product had a very simple interface: we provided one API for sending data about user behavior and another to query the fraud score of a user. But as our customer base grew, we needed better internal tools to debug and surface customer issues.