Building a Feature Proposal and Voting System with React, NodeJS, and DynamoDB

🐙 GitHub | 🎮 Demo

In this article, we’ll create a lightweight solution that enables users to propose new features for our web application and vote on them. We will utilize React for the front-end and construct a simple NodeJS API for the back-end, integrating DynamoDB as our database. Although the source code for this project is hosted in a private repository, all reusable components and utilities are accessible in the RadzionKit repository.

Introduction to Feature Proposal and Voting System

At Increaser, our community page is the central hub for all social interactions within the application. Currently in its early stages, the page features a panel for users to edit their profiles, a leaderboard, the founder’s contact information, and a widget for proposed features, which we’ll explore further in this article. We have adopted a minimalist design for the features widget, using a single list with a toggle to switch between proposed ideas and those that have already been implemented. Although an alternative layout could include a “TO DO,” “IN PROGRESS,” and “DONE” board, our workflow typically involves focusing on one feature at a time, making the “IN PROGRESS” column redundant. Additionally, we aim to keep users focused on voting for new ideas rather than being distracted by completed features.

We use a dedicated DynamoDB table to store proposed features for Increaser. Each item in this table includes several attributes:

id: A unique identifier for the feature.

name: The name of the feature.

description: A brief description of the feature.

createdAt: The timestamp marking when the feature was proposed.

proposedBy: The ID of the user who proposed the feature.

upvotedBy: An array of user IDs who have upvoted the feature.

isApproved: A boolean indicating whether the feature has been approved by the founder.

status: The current status of the feature, with possible values including “idea” or “done”. If you prefer to display the features on a board, you might consider adding a status such as “in progress”.

API Design and Feature Management Workflow

Our API includes just three endpoints dedicated to managing features. If you’re interested in learning how to efficiently build backends within TypeScript monorepos, be sure to explore this insightful article.

The proposeFeature method is crucial to our feature proposal process. It identifies the user’s ID from a JWT token included in the request, which is used for user authentication. To stay informed about new proposals, I’ve set up a Telegram channel where the API sends notifications detailing the proposed features. Upon receiving a message on this channel, I access the DynamoDB explorer on AWS to verify the feature’s validity and refine the name and description for easier comprehension by other users. Although we could monitor new features with a separate Lambda function that listens to the DynamoDB stream, the current setup of direct notifications from the API is effective, especially as this is the only method for proposing features.

Before adding a new feature to the DynamoDB table, we initialize default fields. The isApproved field is set to false, indicating that the feature has not yet been reviewed. The status is set to idea. The proposedBy field captures the user ID of the proposer. Additionally, the upvotedBy field starts with an array containing the proposer’s ID, ensuring that each new feature begins with one upvote.

We organize all functions for interacting with the “features” table into a single file. Utilizing helpers from RadzionKit, such as makeGetItem, updateItem, and totalScan, makes it easy to add new tables to our application.

The voteForFeature method toggles the user’s vote for a feature. If the user has already upvoted the feature, the method removes their vote; otherwise, it adds it. This approach ensures that users can only vote once for each feature.

The features method retrieves all features from the DynamoDB table but filters out unapproved features, ensuring that only the proposer can view their unapproved ideas. Additionally, this method calculates the number of upvotes for each feature and checks if the current user has upvoted the feature. Instead of returning the entire list of user IDs who have upvoted, it provides a more streamlined output.

Front-End Implementation: Building the Feature Voting Interface

With the server-side logic established, we can now turn our attention to the front-end implementation. The widget is displayed on the right side of the community page using the ProductFeaturesBoard component.

We render the content within a Panel component, which is set to have a minimum width of 320px and occupies the remaining space in the parent container. The header displays the title “Product Features” and includes the ProductFeaturesViewSelector component, allowing users to toggle between the “idea” and “done” views. The RenderProductFeaturesView component is used to conditionally display a prompt for proposing new features, ensuring it is visible only when the “idea” view is selected. The ProductFeatureList component is then used to display the list of features.

It’s a common scenario to need a filter or selector for switching between different views. To facilitate this, we utilize the getViewSetup utility from RadzionKit. This utility accepts a default view and a setup name, returning a provider, hook, and renderer that enable convenient conditional rendering based on the current view. For the selector component, we use the TabNavigation component from RadzionKit, which takes an array of views, a function to get the view name, the active view, and a callback to set the view.

Enhancing User Interaction: Feature Proposal Components

The ProposeFeaturePrompt component displays a call-to-action using the PanelPrompt component. When activated, it reveals the ProposeFeatureForm component. Additionally, we employ the Opener component from RadzionKit, which acts as a wrapper around useState for conditional rendering. While I prefer using the Opener for its streamlined syntax, you might find using a simple useState hook more to your liking.

In the ProposeFeatureForm component, users input a name and description for their feature idea. We keep validation simple, only ensuring that these fields are not empty, as I manually approve and edit each feature later. The form’s onSubmit function checks if the submit button is disabled and, if not, it calls the mutate function from the useProposeFeatureMutation hook with the new feature details. Once the mutation is initiated, the onFinish callback is invoked to notify the parent component that the submission process is complete, prompting the ProposeFeaturePrompt to display the PanelPrompt again.

Dynamic Feature Listing and User Interaction Components

To display the list of features, we first retrieve the query result from the API using the useApiQuery hook, which requires the name of the method and the input parameters. The QueryDependant component from RadzionKit is utilized to manage the query state effectively. During the loading state, we display a spinner; in the error state, an error message is shown; and in the success state, we render the list of features. The retrieved features are then divided into two arrays: myUnapprovedFeatures, which contains features proposed by the current user but not yet approved, and otherFeatures, which includes all other features sorted by the number of upvotes in descending order. Each feature is rendered using the ProductFeatureItem component.

To minimize prop drilling, the ProductFeatureItem component is provided with the current feature using the CurrentProductFeatureProvider component. Recognizing the frequent need to pass a single value through a component tree, I created the utility function getValueProviderSetup in RadzionKit. This generic function accepts the name of the entity and returns both a provider and a hook for that entity, streamlining the process of passing contextual data to nested components.

The ProductFeatureItem component displays the feature’s name, a cropped description, and includes a voting button. To facilitate two actions within a single card, the component uses a specific layout pattern. Users can click on the card to open the feature details in a modal, while the “Vote” button allows them to vote for the feature separately. Due to HTML constraints that prevent nesting buttons, we utilize a relatively positioned container for the card, with the “Vote” button absolutely positioned within it. This layout pattern is common enough that RadzionKit provides an abstraction for it, known as ActionInsideInteractiveElement, which simplifies the implementation of multiple interactive elements in a single component.

We utilize the Opener component again to manage the modal state for displaying feature details. To ensure that the title does not overlap with the absolutely positioned “Vote” button, we insert a “Spacer” component with the same dimensions as the “Vote” button, as determined by ActionInsideInteractiveElement. To keep the card’s appearance concise, we crop the description using the maxTextLines CSS utility from RadzionKit. Additionally, if the feature has not been approved yet, we display a ShyInfoBlock component to inform the user that their feature is awaiting approval.

The VoteForFeature component utilizes the UpvoteButton to provide a straightforward and intuitive voting interface. When clicked, the component triggers the mutate function from the useVoteForFeatureMutation hook, with the feature ID passed as an input parameter. The UpvoteButton features a chevron icon and displays the count of upvotes. It dynamically changes color based on the value prop to visually indicate whether the user has already voted for the feature.

The ProductFeatureDetails component displays the feature’s creation date, the user who proposed the feature alongside the voting button, and the full feature description. To fetch the proposer’s profile details, we use the UserProfileQueryDependant component. This component determines if the user has a public profile, displaying their name and country, or labels them as “Anonymous” if they maintain an anonymous account. The UserProfileQueryDependant is an enhancement of the QueryDependant component, providing a more streamlined approach to accessing user profile information.

Please follow and like us: