Introducing Resourcerer: Declarative React Data-Fetching for REST APIs
October 17, 2019 2:30 pmWe 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 React
September 21, 2016 8:05 pmIn 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 pmAdventures 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 React
June 9, 2015 6:32 pmIn 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 Friends
May 19, 2015 10:25 pmA 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 applications
May 7, 2015 5:41 pmSift 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 1
April 28, 2015 8:06 pmTwo 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.