Feed powered byStream Blue Logo Copy 5Created with Sketch.
Redux.js

Redux.js

Application and Data / Libraries / State Management Library

Decision about GitHub, Gatsby, Netlify, styled-components, Redux.js, React, Firebase, Google, Frontend, ReactRally

Avatar of johnnyxbell
Sr. Software Engineer at StackShare
GitHubGitHub
GatsbyGatsby
NetlifyNetlify
styled-componentsstyled-components
Redux.jsRedux.js
ReactReact
FirebaseFirebase
#Google
#Frontend
#ReactRally

I was building a personal project that I needed to store items in a real time database. I am more comfortable with my Frontend skills than my backend so I didn't want to spend time building out anything in Ruby or Go.

I stumbled on Firebase by #Google, and it was really all I needed. It had realtime data, an area for storing file uploads and best of all for the amount of data I needed it was free!

I built out my application using tools I was familiar with, React for the framework, Redux.js to manage my state across components, and styled-components for the styling.

Now as this was a project I was just working on in my free time for fun I didn't really want to pay for hosting. I did some research and I found Netlify. I had actually seen them at #ReactRally the year before and deployed a Gatsby site to Netlify already.

Netlify was very easy to setup and link to my GitHub account you select a repo and pretty much with very little configuration you have a live site that will deploy every time you push to master.

With the selection of these tools I was able to build out my application, connect it to a realtime database, and deploy to a live environment all with $0 spent.

If you're looking to build out a small app I suggest giving these tools a go as you can get your idea out into the real world for absolutely no cost.

22 upvotes4 comments9.6K views

Decision at Eventbrite about React, Redux.js, Flux, Marionette, Backbone.js

Avatar of Golodhros
Sr. Software Engineer at Eventbrite
ReactReact
Redux.jsRedux.js
FluxFlux
MarionetteMarionette
Backbone.jsBackbone.js

We are in the middle of a change of the stack on the front end. So we used Backbone.js with Marionette. Then we also created our own implementation of a Flux kind of flow. We call it eb-flux. We have worked with Marionette for a long time. Then at some point we start evolving and end up having a kind of Redux.js-style architecture, but with Marionette.

But then maybe one and a half years ago, we started moving into React and that's why we created the Eventbrite design system. It's a really nice project that probably could be open sourced. It's a library of components for our React components.

With the help of that library, we are building our new stack with React and sometimes Redux when it's necessary.

13 upvotes1.7K views

Decision at Stitch Fix about Apache Spark, Victory, Amazon S3, Elasticsearch, Redux.js, React

Avatar of psunnn
Software Engineer at Stitch Fix
Apache SparkApache Spark
VictoryVictory
Amazon S3Amazon S3
ElasticsearchElasticsearch
Redux.jsRedux.js
ReactReact

As a frontend engineer on the Algorithms & Analytics team at Stitch Fix, I work with data scientists to develop applications and visualizations to help our internal business partners make data-driven decisions. I envisioned a platform that would assist data scientists in the data exploration process, allowing them to visually explore and rapidly iterate through their assumptions, then share their insights with others. This would align with our team's philosophy of having engineers "deploy platforms, services, abstractions, and frameworks that allow the data scientists to conceive of, develop, and deploy their ideas with autonomy", and solve the pain of data exploration.

The final product, code-named Dora, is built with React, Redux.js and Victory, backed by Elasticsearch to enable fast and iterative data exploration, and uses Apache Spark to move data from our Amazon S3 data warehouse into the Elasticsearch cluster.

9 upvotes1.8K views

Decision at StackShare about Redux.js, Apollo, React, GraphQL, FrontEndFrameworks

Avatar of ruswerner
Lead Engineer at StackShare
Redux.jsRedux.js
ApolloApollo
ReactReact
GraphQLGraphQL
#FrontEndFrameworks

Earlier this year we decided to go "all-in" on GraphQL to provide our front-end API. We needed a stable client library to power our React app. We decided to use Apollo Client for a few reasons:

1) Stability 2) Maturity 3) Heaps of features 4) Great documentation (with use cases) 5) Support for server-side rendering 6) Allowed us to stop using Redux and Mobx

Overall we've had great success with this library, along with a few minor hiccups and work arounds, but no show stoppers. If you are coming from Redux.js land, it takes a bit of time to settle into a new way of thinking about how your data is fetched and flows through your React app. This part has been the biggest learning curve of anything to do with GraphQL.

One of the downsides to Apollo Client, once you build a larger application, (past the size of most of the documented use cases and sample apps) the state management tends to get distributed through various places; and not just components. Apollo Client has a state management feature that relies on a normalised local cache. Mastering the knowledge of how this works is key to getting the most out of the library and to architecting your component hierarchy properly.

#FrontEndFrameworks

8 upvotes1 comment661 views

Decision at Algolia about MobX, Redux.js, AngularJS, React

Avatar of proudlygeek
MobXMobX
Redux.jsRedux.js
AngularJSAngularJS
ReactReact

We started rebuilding our dashboard components using React from AngularJS over 3 years ago and, in order to have predictable client-side state management we introduced Redux.js inside our stack because of the popularity it gained inside the JavaScript community; that said, the number of lines of codes needed to implement even the simplest form was unnecessarily high, from a simple form to a more complex component like our team management page.

By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.

7 upvotes2 comments2.1K views

Decision about Redux.js, Bugsnag, Sentry, LogRocket, JavaScript, React, OpenSource, Chrome, OpenSorce, ErrorBoundry

Avatar of johnnyxbell
Sr. Software Engineer at StackShare
Redux.jsRedux.js
BugsnagBugsnag
SentrySentry
LogRocketLogRocket
JavaScriptJavaScript
ReactReact
#OpenSource
#Chrome
#OpenSorce
#ErrorBoundry

For my portfolio websites and my personal OpenSource projects I had started exclusively using React and JavaScript so I needed a way to track any errors that we're happening for my users that I didn't uncover during my personal UAT.

I had narrowed it down to two tools LogRocket and Sentry (I also tried Bugsnag but it did not make the final two). Before I get into this I want to say that both of these tools are amazing and whichever you choose will suit your needs well.

I firstly decided to go with LogRocket the fact that they had a recorded screen capture of what the user was doing when the bug happened was amazing... I could go back and rewatch what the user did to replicate that error, this was fantastic. It was also very easy to setup and get going. They had options for React and Redux.js so you can track all your Redux.js actions. I had a fairly large Redux.js store, this was ended up being a issue, it killed the processing power on my machine, Chrome ended up using 2-4gb of ram, so I quickly disabled the Redux.js option.

After using LogRocket for a month or so I decided to switch to Sentry. I noticed that Sentry was openSorce and everyone was talking about Sentry so I thought I may as well give it a test drive. Setting it up was so easy, I had everything up and running within seconds. It also gives you the option to wrap an errorBoundry in React so get more specific errors. The simplicity of Sentry was a breath of fresh air, it allowed me find the bug that was shown to the user and fix that very simply. The UI for Sentry is beautiful and just really clean to look at, and their emails are also just perfect.

I have decided to stick with Sentry for the long run, I tested pretty much all the JS error loggers and I find Sentry the best.

6 upvotes2.9K views

Decision about Yarn, Redux.js, React, jQuery, vuex, Vue.js, MongoDB, Redis, PostgreSQL, Sidekiq, Rails, Font-awesome, Bulma.io

Avatar of cyrusstoller
YarnYarn
Redux.jsRedux.js
ReactReact
jQueryjQuery
vuexvuex
Vue.jsVue.js
MongoDBMongoDB
RedisRedis
PostgreSQLPostgreSQL
SidekiqSidekiq
RailsRails
#Font-awesome
#Bulma.io

I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.

On the front-end I'm using Vue.js and vuex in combination with #Turbolinks. In effect, I want to render most pages on the server side without key interactions being managed by Vue.js . This is the first project I'm working on where I've explicitly decided not to include jQuery . I have found React and Redux.js more confusing to setup. I appreciate the opinionated approach from the Vue.js community and that things just work together the way that I'd expect. To manage my javascript dependencies, I'm using Yarn .

For CSS frameworks, I'm using #Bulma.io. I really appreciate it's minimal nature and that there are no hard javascript dependencies. And to add a little spice, I'm using #font-awesome.

5 upvotes1.2K views

Decision about GitLab, Git, WebStorm, Amazon DynamoDB, AWS CloudFormation, AWS Lambda, Go, Bootstrap, redux-saga, Redux.js, React, JetBrains, Serverless

Avatar of devalias
Hack. Dev. Transcend.
GitLabGitLab
GitGit
WebStormWebStorm
Amazon DynamoDBAmazon DynamoDB
AWS CloudFormationAWS CloudFormation
AWS LambdaAWS Lambda
GoGo
BootstrapBootstrap
redux-sagaredux-saga
Redux.jsRedux.js
ReactReact
#JetBrains
#Serverless

Working on a project recently, wanted an easy modern frontend to work with, decoupled from our backend. To get things going quickly, decided to go with React, Redux.js, redux-saga, Bootstrap.

On the backend side, Go is a personal favourite, and wanted to minimize server overheads so went with a #serverless architecture leveraging AWS Lambda, AWS CloudFormation, Amazon DynamoDB, etc.

For IDE/tooling I tend to stick to the #JetBrains tools: WebStorm / Goland.

Obviously using Git, with GitLab private repo's for managing code/issues/etc.

5 upvotes1.1K views

Decision about Apache Cordova, redux-saga, React Native, AngularJS, Redux.js, React, JavascriptMvcFrameworks

Avatar of aharonamir
Apache CordovaApache Cordova
redux-sagaredux-saga
React NativeReact Native
AngularJSAngularJS
Redux.jsRedux.js
ReactReact
#JavascriptMvcFrameworks

We had contemplated a long time which #JavascriptMvcFrameworks to use, React and React Native vs AngularJS and Apache Cordova in both web and mobile. Eventually we chose react over angular since it was quicker to learn, less code for simple apps and quicker integration of third party javascript modules. for the full MVC we added Redux.js for state management and redux-saga for async calls and logic. since we also have mobile app along with the web, we can shere logic and model between web and mobile.

4 upvotes1.6K views

Decision about Elm, Redux.js, React

Avatar of zaaack
ElmElm
Redux.jsRedux.js
ReactReact

React is awesome, but is just a view library, when we need to manage state, there is Redux.js. The ecosystem of redux is big, complex and hard to integrate. That's why we choose to create hydux. Hydux is simple, the main idea is from Elm, a pure functional vdom-based framework for front-end. We seperate the whole app with state, actions and views. Which means not only our views are a tree, but also our state and actions. Reuse state and actions are just like reuse react components, no need to consider dependences.

2 upvotes1.1K views