Posts

Showing posts from February, 2019

31. Media Library - Getting started with Images

At this point we can finally start to think about loading images to the system. However, before we start uploading images we need to put the pieces in place to store data relating to images. Code  https://github.com/fullsapps/media-library/tree/31.ImagesGettingStarted Background  In this post we are going to add images to Redux following the same patterns we have seen with objects such as properties and settings. Walk Through We know this pattern well at this point, so, I am going to jump right in. We are going to create our images data layer and expose it via the Redux store. Let's start by creating our images data layer. This is all stuff we have seen before. Note that we are associating images to properties and storing the association on the image itself. firebase/db/images.js import { db } from '../firebase'; export const setImage = async (image) => {   try {     return await db       .collection('images')       .doc(image.id)  

30. Media Library - Admin Property

We previously created a landing page to administer or manage a property but we have left it blank to this point. In this post we will work on this page. Code  https://github.com/fullsapps/media-library/tree/30.AdminProperty Background  In this post we are going to follow patterns that we have used before. We will go another layer deeper into inception (that's a movie reference that probably dates me) by adding another layer of nested menus and routing. We will also prepare for the creation of an image object that will be stored in global state. Again, we are using Redux as a cache to prevent constant round trips to the back-end to get data. Walk Through If you are running the app, you can click on the Manage button in the Admin Properties list and you will see a unique component being rendered by React Router. You can confirm this by inspected the URL in the address bar. I am going to start by turning this into a bit of a landing page that separates the property detail

29. Media Library - More Testing

We have written a lot of code in past few posts. I want to add tests and also I want to see if there are opportunities to standardize the way we approach testing of the different "things" we are creating. Code  https://github.com/fullsapps/media-library/tree/29.TestingCont Background  I started thinking that it might really benefit our application to think about testing more holistically. Throughout this project we have written tests that largely cover our application. However, we have done so in a sort of ad-hoc manor. We've written a lot of code at this point and it might really be helpful to think about testing more systematically. Some of what I discuss below has been discussed in previous posts. This post also provides an opportunity to collect all of our disparate thoughts on testing. I want to start by breaking down the different "things" (that's a technical term) we are creating in our application. These are rough categories for the code w

AWS Amplify Authorization Pattern

In this post I want to discuss one option for authorizing users to do "stuff" in a React web app built using AWS Amplify. We've walked through the process for creating React web apps that leverage AWS Amplify in other posts so I am going to assume if you are reading this you are familiar with the process. Getting Started I am going to leverage the @auth directive provided by Amplify. You can (and should) read more about that here: https://aws-amplify.github.io/docs/cli/graphql#auth . In order to use @auth there are some prerequisites. Authentication - we must be using AWS Cognito authentication from Amplify as outlined here (amplify add auth):  https://aws-amplify.github.io/docs/js/authentication . API - we must be using AWS AppSync (GraphQL) for our API from Amplify as outlined here (amplify add api): https://aws-amplify.github.io/docs/js/api . We must be using the @model directive to tie our API to an AWS DynamoDB backend as outlined here:  https://aws-amplify.

28. Media Library - Settings front-end

In this post we will begin wiring up the ability to manage settings in our GUI. Code  https://github.com/fullsapps/media-library/tree/28.SettingsFrontend Background  In the previous post we discussed a desire to keep settings functionality generic to allow additional settings to be added and managed without requiring any new code. In this post we will continue that theme with our construction of the setting GUI. With that said, the patterns applied to settings will be very similar to the patterns applied to properties. Walk Through We previously created a landing page to manage (or administer) settings. With our back-end in place we can start to build out our admin settings GUI. I'm going to start by wrapping our AdminSettings component in a container to get access to the settings state that we are now exposing via the Redux store. We have used this same container pattern elsewhere in our application. AdminSettingsContainer.jsx import { connect } from 'react

27. Media Library - Settings back-end

This post is going to feel like a bit of a repeat of #25 where we added the back-end to support the administration of Properties. In this case we are going to add the back-end support for Settings. We will use settings when we manage individual properties, specifically, the settings we want to manage will be applied to the images loaded to the Media Library. Code  https://github.com/fullsapps/media-library/tree/27.SettingsBackend Background We want to be able to apply metadata to the images loaded to Media Library. This will help us find and filter images when we are looking for them. Some metadata will be structured and that is what we want to manage in this post. As much as possible we want to keep the management of settings generic. That is, if someone wants to add a new settings with a list of values they should be able to leverage the pieces we put in place in this post, and it should not require additional code to be written. To get started we are going to support thr