/Book-a-concert-front-end

"Book a Concert" is a Single Page Application (SPA) and an API designed to assist users in booking concerts or creating independent events for others to book. Users can register, reserve, create independent concerts, or cancel an event if they are the organizer. Built with React, Redux, Tailwind CSS, Ruby on Rails, and PostgreSQL.

Primary LanguageJavaScriptMIT LicenseMIT


README

📗 Table of Contents

📖 Reserve a Concert

Would you like to learn more?

Reserve a Concert is a web platform where users can create and manage events or concerts, allowing others to book tickets for their events or attend events hosted by others. The frontend of the application is managed in this repository, while the backend is powered by an API built with Ruby on Rails.

Kanban Board

  • Take a look to the Project Kanban Board
  • Final number of team members: 3
  • Kanban Initial state below:
kanban

🛠 Built With

Tech Stack

Would You like to learn more about the techs we have used so far?

Client
Tests
Server
Database

Key Features

Some Interesting features

  • Any user can create a concert event
  • The Event organizer can remove or cancel a Concert, and that will cancel all reservations
  • Any user can book for other user's concert
  • User can create an account
  • User can see their current reservations

(back to top)

🚀 Live Demo

(back to top)

💻 Getting Started

Would you like to make use of this project?

To get a local copy up and running, follow these steps.

Prerequisites

First Make sure YOu have installed

  • git
  • node
  • A code editor, the most used is vscode but you can chose any other.

We do recommend to work on linux

Setup

Open you desired folder within you terminal:

  cd my-folder

Then clone the project repository in you current folder

  git clone git@github.com:Diegogagan2587/Book-a-concert-front-end.git

Install

to install project follow next steps:

  1. Open the project folder
  cd Book-a-concert-front-end
  1. then install require dependencies:
npm install
  1. As the last step, you'll need to create a .env file in the root folder of the project as shown below:
  //.env

  VITE_API_URL_BASE='http://127.0.0.1:3001'

Note: Please make sure that VITE_API_URL_BASE correspond to your desired API base, in this case we are assuming that you have already installed and running the Rails API in local on your computer, if you don't, get it here: Book A Concert - Back End.

Everything should be ready now!

Usage

To run the project, execute the following command:

  npm run dev

Run tests

We have implemented test using Vitest, React Testing Library and MSW for mocking responses from the API. If you would like replicate the settings for our test please refer to Introduction To React Testing from The Oding Project;

To run tests, run the following command:

  npm run test

Deployment

You can deploy locally this project using:

npm run build

Don't forget to set up you environmental variables in production:

  • API_URL_BASE = your_api_base_url_here

(back to top)

👥 Authors

You still here? Let's connect!

👤 Rudi Carrillo

👤 Diego Vidal Lopez

👤 Dani Morillo

(back to top)

🔭 Future Features

Some features we might implement:

  • Cancel a reservation

(back to top)

🤝 Contributing

Contributions, issues, and feature requests are welcome!

Feel free to check the issues page.

Naming branches conventions

Before submitting a pull request please read the original article we based our naming branching conventions Naming conventions for Git Branches - a Cheatsheet by Abhay Amin in medium. Check some examples with prefixes below:

  • feat/branch-name branches that implement a new feature or enhancement
  • fix/branch-name branches that fix a bug
  • docs/branch-name branches that works on documentation

We are open to other prefixes as long as they are clear and follow general branching conventions. also please note that expect you to submit pull requests from feature branches.

Commit Conventions

Stick to conventions can bring benefits like better clarity in code reviews, we strive to use the following prefixes in our commits:

  • feat/element when new functionality is added.
  • fix/element when a bug on element is fixed.
  • chore/ daily task not related to features of errors, like adding elements to .gitignore or installing a dependency.
  • test/ if we add or fix a test.
  • docs/ when only documentation is updated.
  • build/ when the change affects only compilation of the project.
  • ci/ Changes that affect continuous integration.
  • style/ Changes that affect code formatting and does not affect functionality.
  • perf/ Changes that affect performance.
  • revert Automatically implemented by git, but it is used for changes that revert a commit.

What we value from pull request

We appreciate clean contributions, that highlights main changes, if you plan to format the file, might be good idea to do it in another pull request to make changes that affect functionality easier to read by separate them from those than only affect formatting.

(back to top)

⭐️ Show your support

Feel free to leave us an star on this repo.

(back to top)

🙏 Acknowledgments

Learn about people that impact our project:

I'd like to express my gratitude to everyone who made this project possible.

Thanks again to everyone who believed in this project and helped make it a reality!

Furthermore, special recognition is due to Murat Korkmaz, the author of this design that served as inspiration for our work

  • Thanks to uxwing for providing some icons

(back to top)

❓ FAQ (OPTIONAL)

Discover some Frequent Ask Questions

  • What if I want to modify this project according to my requirements?

    • Consider forking the repository, you will get access that way to modify the project and get your own version

  • What if I have a suggestion?

    • Please visit the Issues Page linked before and submit your suggestion there.

(back to top)

📝 License

This project is MIT licensed.

(back to top)