This post provides more detail about my Spendr online banking prototype.
Try out the Spendr live demo.
The source code can be viewed on the Spendr GitHub repository.
To see the rest of my portfolio, visit my portfolio website.
This project served one purpose: Demonstrate for employers my competency with React and Redux. I think it achieves that purpose, but I will follow it up with another React project.
While the subject of the site is a new approach to online banking (one that attempts to reduce spending frequency by requiring explicit approval of each transaction before the transaction is processed) my focus is more on the execution and technique of creating the website.
I'd like to call attention to a few noteworthy parts:
- The visual appearance is clean.
- Information is clearly presented.
- All colours (fonts and backgrounds) meet W3C (World Wide Web Consortium) WCAG 2.0 (Web Content Accessibility Guidelines) minimum contrast ratio of 4.5:1.
- HTML (hyper text markup language) is structured with necessary W3C ARIA (Accessible Rich Internet Applications) attributes to deliver a screen reader capable experience. See video demonstrating screen reader usage.
Visual Appearance
The visual appearance looks nice, in my opinion, and the design is clean and simple, which I think delivers the information well.
Accessible Colours
Google now presents contrast information in their widget for picking text colours. Making an accessible web application has become easier.
Screen Readers
When I first tried using screen reader software on Spendr I found out it was impossible to understand. After a day of learning to use Google Chrome's Vox screen reader extension, and making plenty of changes to my HTML structure and employed ARIA attributes, I finally created what I think is a screen reader capable site. Below is a video demonstration of myself using a screen reader to navigate the Spendr site.
React and Redux
A lingering question I have regarding Redux is: What state do you leave out of Redux?
- Current list of transactions: Put in redux.
- Currently detailed transaction: Put in redux.
- Currently focused transaction: Hmm...
For example, redux doesn't store the entire state of the interface, such as the current DOM (Document Object Model) nodes. It would be ridiculous to store all that information in redux. Yet, my understanding of redux is that it stores all of your application state. Isn't the state of the interface, even what transaction is currently focused by the browser, part of the state of the application?
The issue I ran into was in trying to manipulate the DOM, such as focusing specific elements, but not having sufficient information in my Redux state to do what I wanted. I didn't want to put that information into Redux, and so stored it other places.
But the question remains, what application state (like interface state) do you leave out of Redux?
I think I will become better able to answer that question as I gain more experience with React and Redux.
Try out the Spendr live demo.
The source code can be viewed on the Spendr GitHub repository.
To see the rest of my portfolio, visit my portfolio website.
Top comments (3)
As a rule of thumb, any shared state in your application would live in your redux store. Any state specific to a single component, should live within that component.
The main thing you want to avoid is using redux as the state for your controlled/uncontrolled components. You usually want to use class state to handle the events (onChange, onClick) and in some cases, transfer that state to a redux store using debouncing. If you were to debounce the onChange event, the UI would seem slow and janky.
Note for most use cases, just using the class/component state should be sufficient. Redux is for more advanced use cases and shared state.
I work on a production application which a piece of, in a simple sense can be thought of as a form. Our form has different fields, but depending on the user, not always the same fields. Regardless of what fields are displayed, we need to validate and submit the data.
We keep event based state directly in the component, then debounce changes to our redux store where we store the entire state of the form as well as having dispatcher's which validate and submit the stored form data.
Maybe not the most convential use case, but may convey the layer of separation a bit.
I might have rambled a bit there, hopefully helpful!
Thanks for the reply. I didn't think anyone would respond. Since this seems like a really cool community, I should probably put questions in a more apparent place in my posts.
I thought I had read a lot about Redux, but your post is the first place I've seen that mentions what kind of data can exist outside of Redux. Or, at least the first place I've noticed it.
I thought of Redux as a framework which, if employed, all state is managed by it. However, your experience is of keeping controlled/uncontrolled component state out of it and instead using Redux as just a place to share state across the application. And complex state, at that.
The more I think of your example, the more I see the benefit of keeping that complex state in one concise and controlled place to then submit at a later date.
This was my first Redux project past the tutorial documentation. For my next project that uses Redux/React I will definitely keep your input in mind. Thanks for the comment, it helped me out a lot!
No problem 😊 glad it was of some use to you.I don't post on here often, trying to make it a more regular thing. Definitely an amazing community here.
There's a bunch of good articles on the interwebs which provide other real world examples as well. This is a good one blog.logrocket.com/why-use-redux-r... as well as anything along the lines of "you might (not) need Redux", a few by Dan Abramov himself!