Posts

Showing posts from December, 2018

8. Media Library - Navigation: Semantic UI React Menus

In this post we will start to put together our navigation strategy for the application. We will use various components from Semantic UI React to drive navigation, primarily menus, in coordination with React Router. Semantic UI React Menu -  https://react.semantic-ui.com/collections/menu/ Code https://github.com/fullsapps/media-library/tree/8.Navigation Requirements We do have some  navigation requirements. Our app will have explicit navigation (menus) to get to the various parts of the application. Our navigation needs to reflect the overarching requirement that our application be responsive. Navigation needs to reflect our authorization model and not present access to parts of the application that should be inaccessible based on a user's role.. Navigation We will leverage the Menu component from Semantic UI React extensively for on-screen navigation (with behavior driven by React Router). We will take inspiration (and a lot of code) from a layout sample prov

7. Media Library - Testing Revisited: react-testing-library

Code  https://github.com/fullsapps/media-library/tree/6%267.LazyLoadingTestingRedux Choices  If you are joining this blog series on this post you should review the previous post. In fact, you likely will need to review the whole series for any of these posts to make sense. In post 4 (Testing) we established a testing strategy for our app that leveraged Enzyme. In post 6 (Lazy Loading) we decided to upgrade to React 16.7 (alpha) to take advantage of (and to experiment with) some of the new features of React. This broken out tests, per  https://github.com/airbnb/enzyme/issues/1917 . As a result, we decided to move away from Enzyme and move to react-testing-library. Background on react-testing-library react-testing-library was created because the author (Kent C. Dodds) was frustrated with Enzyme and believed it encouraged too much focus on implementation details. As a result, react-testing-library focuses on testing the DOM (that gets rendered from components) and not component

6. Media Library - Lazy Loading: React.lazy & React.Suspense

Code  https://github.com/fullsapps/media-library/tree/6%267.LazyLoadingTestingRedux (note: this includes code discussed in the next post) Choices  Lazy loading, or code splitting, is simply the practice of splitting an app into smaller chunks so that the whole app does not need to be loaded at once. We then only delivery chunks of code as the user requires them. This results in the app taking less time to load, which improves user experience. Various techniques have been used in React to provide this capability. Most recently, in React 16.6, React added lazy and Suspense, which provide the most recent mechanism for code splitting. Walk Through In our app (in its current state) we always want to load the Login component. However, the user, if registered, is unlikely to use the Register component. Similarly, the ForgotPassword component will only be useful occasionally and the Admin component will only be useful to Administrators, so we don't want to load it for all use

5. Media Library - Routing: React Router

Code  https://github.com/fullsapps/media-library/tree/5.Routing Choices  Our application is going to use React Router ( https://github.com/ReactTraining/react-router ). I think of React Router as the defacto standard for routing in React. It is currently at version 4 and is well used and respected by the React community. The one other option I have looked at briefly is Reach Router ( https://github.com/reach/router ). To save time I am going to stick with React Router because I have some experience with it but Reach Router looks to have gained a bit of traction with key members of the React community and is another viable option. Additionally, the documentation for React Router is fantastic (for web) : https://reacttraining.com/react-router/web/guides/quick-start Requirements We do have a few routing requirements. We need a mechanism to prevent users who are not logged in from accessing the application. We need a mechanism to separate user activities and administrator

4. Media Library - Testing: Jest and Enzyme

IMPORTANT!  I am going to replace the testing framework outlined in this post in a subsequent post (7. Media Library). The information outlined here is still relevant. The part that gets replaced is Enzyme (and its dependencies). You may want to skip the Walk Through, or if you prefer you can follow the Walk Through and we will eventually uninstall the Enzyme bits. The reason for this change is explained in subsequent posts. Code  https://github.com/fullsapps/media-library/tree/4.Testing Choices  I am going to assume we all agree on the merits of testing. My goal is 100% automated test coverage with any project. We will probably take a few shortcuts in this project and not test everything (or, at least not test everything as deeply as we may want). In keeping with our "move quickly" philosophy the tests will probably remain light until something indicates further investment in testing is warranted. For example, if a bug is reported, I will often fix the bug and try t

3. Media Library - UI Framework - Semantic UI (React)

Code  https://github.com/fullsapps/media-library/tree/3.UIFramework Application Requirements  We have some basic requirements when it comes to styling our application. The application must be responsive. Our goal is to provide a usable experience on both mobile and desktop. There is no requirement (or need), at this time, for dedicated mobile apps. The application is somewhat utilitarian. The look and feel of the application needs to support a good user experience but in and of itself will not attract users to the application.  It is not required that our application have a unique or independent look and feel. In fact, because of the utilitarian nature of our application, it will likely aid users if we follow patterns they are already familiar with in other applications. The look and feel of our application, and even the usability, may need to change in time. So, we will make choices that focus on moving quickly, and adjust in the future if required. Choices In my ex

2. Media Library - Bootstrapping the App: Create React App

Code  https://github.com/fullsapps/media-library/tree/2.BootstrappingTheApp Choices  I am using Create React App to bootstrap the application. The will be a few purists out there that frown on this but they need to get with the times. The purists would opt for more control, better "understandability", etc. At this point in time I can't imagine their are many people out there that don't believe Create React App is a solid way to bootstrap your React application.  It provides a tremendous amount of value.  It saves me from writing a ton of code.  This is directly in line with my philosophy - if there is a good tool available that saves time, use it. If you are using Create React App, I recommend you don't use it blindly and that you read (and follow) the user guide: https://facebook.github.io/create-react-app/ .  The guide is excellent and very useful.  It provides some very useful direction for things like testing, styling, code formatting, etc. ESLint an

1. Media Library - Dev setup

Choices  I am going to be using Visual Studio Code as my code editor. This seems like the most popular choice these days and I have been using it for quite a while and like it. I am a bit of a dinosaur and still run Windows. If you do use Visual Studio Code on Windows, make sure you always Run as Administrator - it will reduce the number of weird errors you get. I am going to walk through my particular setup in more detail below. I am going to be using Git/Github as my repository and for code sharing. For writing public code I don't think there is really another choice (to be clear, there are other choices but Github is the defacto standard). Although, I like Github a lot, I actually use Azure DevOps (recently rebranded from Visual Studio Team Services) on private projects and like it a lot for small teams too. I have also worked with GitLab but I found it a bit needlessly complex. Any of the commercial offerings from folks like Atlassian would work great, but would be overkill

0. Media Library - Introduction

This blog series captures the creation of a new web application. The general idea of the blog series is to discuss a specific set of technologies and a particular pattern for developing a new web application. The series is not meant as a training piece on any particular technology but instead will focus on how a particular tech stack can be used to build a modern web application. We will attempt to focus on a new high-level topic every post. I will not be reproducing every-line of code in this blog. I will make all code available via Github. Instead, we will use this blog to discuss the day-to-day choices a developer needs to make and the particular choices we are making. Philosophy We are going to roughly apply the principals of lean software development to this project. This means we are going to: Be agile Iterate Get moving (and keep moving) Err on the side of moving quickly Expect to refactor Produce usable code as early and as often as possible Make decisions as we g