Series: Building a Social Network with Flask, React & Stream – Part 15
This article is the fourth installment of a tutorial series focused on how to create a full-stack application using Flask, React/Redux and Stream. In this article, we are going to start creating, editing, and fetching collections, or groups of links, for our web application. Be sure to check out the repo to follow along!
For our app, users will be uploading groups of links into objects called collections. If you remember from our last series, these collections will have a name and a description, allowing your users to separate their content into distinct groupings. For myself, I have created a collection for links from the Stream blog to see all of the exciting content that they post!
This example would be very easily adapted if you wanted to create a blog on your website where you can quickly add articles from Medium, Dev.to, etc. It would also be a snap to connect the back-end to RSS feeds to keep tabs on your favorite newspapers.
In this article, we will be looking to recreate the form from our previous vanilla HTML/CSS/JS series that looks a little like this:
As always, I like by defining the requests that I will be making to the back-end. As the requests themselves are the fulcrum on which the front and back-ends communicate, writing them first allows you a great starting point to start structuring both sides.
Since we are going to be doing all the CRUD (Create, Read, Update, Delete) tasks for our collections, we will need to define these new request types in our agent constant.
After that, we will create a new ‘Collections’ constant that will hold the task-specific requests for getting, updating, creating, and deleting those collections. We will need a unique ID to retrieve and update collections, as well as a name and description variables when we create or update them (in
Collection Editor Reducer
Now that our requests are finished, we can move onto creating a reducer to deal with the state of our CollectionEditor component that we will be constructing next. In this component, we will need to handle when the page is loaded (to set the props for the name and description fields if we are updating an existing collection) as well as one to unload and erase the state. After, we will need to handle updating fields from user input, another one to handle form submission, and one for the start of the asynchronous request (in
With the reducer ready to go, we can create our mapStateToProps and mapDispatchToProps constants that will be connected to the CollectionEditor component. We will define our component functions for changing the collection name and description, as well as for submitting a form. Considering that the form will be used for both creating and updating existing forms, we need to include some conditionality for the request to direct it towards the proper route. Given that an existing collection will have an ID value associated while a new one will not, we can create a ternary statement dependent on the existence of that property.
Once our constructor is done, we can create a componentWillReceiveProps lifecycle method to handle when a new collection is loaded as well as a componentWillMount function that will take parameters from the URL to search for the existing collection. As a final touch, we will add another ternary operator to the button rendering to differentiate between creating and updating collections (in
We will need to handle redirection for users after they finish creating a collection, as they might assume if they stayed on the same page that there was some kind of error. We will create redirection for both submission and deletion actions that a user might make for a collection (in
After, we will be creating the routing to the collection editor using our AppRouter component. As before, we import the component at the top of the file, and as we only want authenticated users to be able to create (let alone update) collections, we will wrap the editor in the AuthedRouter HOC (in
To complete our work on the editor, we need users to have a convenient access point so that we can add it to the navigation header component for authenticated users.
With the front-end completed for now, we can head to the back-end to set up the forms and views for our collections. As we have already established the fields in the front end request, we need to allow the collection name and description to be sent and validated in the request. As a collection will need to have both of these fields, we can also set them with DataRequired validators (in
Like our user objects, we will need to provide the front-end with JSON representations of our collections. The front-end currently requires ID, name, and description values, but we will also include a createdAt and author JSON object for good measure (in
A Collection Of Views
In our previous tutorial series, we covered the server-side code for synchronizing our database with Stream, including class methods for the creation, updating, and deleting of collection entries. For a recap of these methods, you can check out the tutorial here.
Our task now is converting the views to return JSON responses for the front-end instead of rendered templates (in
Sanity Check #1
Starting up our server and the watch build of our React app, we check to make sure that everything is working as it should. Navigating to the New Collection tab in the navbar, you should see a basic collection form complete with fields for the name and description, as well as the submission button.
Now that we can create and update a collection, our next step is to create a collection view screen. We already started this process in our common reducer with our redirect after a collection form submission action, although now it will redirect us to our 404 page. We also already have our agent set up for the requests, so we can skip right to the reducer.
We will start by creating a reducer for the collection component. This collection will need to address actions resulting from the loading of the page and assigning the collection to state as the payload of the request. The unloading action will erase the collection and return a blank slate state (in
After the reducer, we can now dig into creating the collection page. We will start with connecting the component to our reducer with mapStateToProps and mapDispatchToProps for the current user, as well as the onLoad and onUnload action dispatch. After that the componentWillMount method will send a request with our collection agent based on the props passed through the URL parameters. ComponentWillUnmount will remove the properties from our store. In our render, we will confirm there is a collection that was returned, if not, it will return the NotFound component.
Much like our profile page, the collection page will need to check against the current user to allow the owner to modify it. We can check the author properties passed with the collection against the current user to determine this ownership. We will also be adding in a CollectionMeta component underneath the name and description to provide metadata for the collection which we will define next (in
The collection metadata will include information about the author, as well as some data for the creation date. The author data will also link to the author to be able to check out their profile page. Beyond that, we will be passing the canModify property to the CollectionActions component that we will now have to create (in
CollectionActions will give the author the ability to edit or delete the collection. As we will be using the delete action defined in the collection reducer, we will need to reference that in mapDispatchToProps. For the component itself, we will check again for the canModify property before rendering (in
Now that the collection component is complete, we will now add it to our AppRouter. We will also provide it as an AuthedRoute so that our content will be able to be loaded from a users Stream credentials if they have access to it (in
Sanity Check #2
As our final sanity check, we will check the collection page of a created collection to ensure that we can see the collectionActions component as the author to be able to edit and delete.
Sanity Check #3
Next, we need to check to make sure that the collection editor is working correctly with a previously defined collection, giving us the ‘Update Collection’ text in our submission button, as well as loading the name and description into the proper fields.
Now, our collection CRUD functions are finished!
We have finally started to add to the real functionality of the site, with collections eventually serving as a jump-off point for integrating chat into our application. In our next article, we will be starting to add in similar components for adding content to the collections, as well as rendering the content as an infinite scroll. We will also be applying that same infinite scroll to the home page as our timeline feed!
As always, thanks for reading and Happy Hacking!
- Keeping Public API in Check With the Kotlin Binary Validator Plugin
- Jetpack Compose: First Impressions and Learning Resources
- Clean Chat Example App with Jetpack Compose
- How Stream Activity Feeds Power CodePen’s Social Development Experience
- React Native: How To Build Bidirectional Infinite Scroll
- Flutter vs React Native: The Ultimate Comparison