Design and architecture

[rossanodan]

Hello everyone!

Since it's a long time I don't contribute to this project, I kind lost the sense of it. I saw there are a lot of ideas but the status of works is not changed a lot. So here I am with some questions.

1. What is the final goal of EddieBotUI?
2. Do we have a design for core features?

@eddiejaoude

We should dedicate some time to formalising these things to have a clearer and common vision about this project - that I find really interesting. Above you can find a small design I did, just to have an idea about the architecture and the code organisation.

[github-actions[bot]]

It's great having you contribute to this project:tada:

Feel free to raise an Issue! Welcome to the community :nerd_face:

If you would like to continue contributing to open source and would like to do it with an awesome inclusive community, you should join our Discord chat and our GitHub Organisation - we help and encourage each other to contribute to open source little and often 🤓 . Any questions let us know.

[BOLT04]

Hi @rossanodan 😃, imo the final goal of EddieBotUI is to have a deployed website that displays all kinds of info about the community like bios, stats, badges, etc. We have some GitHub actions that collect data to the DB, so that info can be on this UI.

As for design for core features, I don't think we have it. We started the repository with React, CSS and Firebase Firestore, then we experimented with Semantic UI React and we were going to move to Bootstrap. But now there will be a DB switch I believe, and the community website uses Tailwind CSS. So I think we can re-think the stack choice and see what everyone else is also comfortable using 😃.

I'd also like to hear the opinion of anyone who is interested in contributing to a front-end project like this one, and @eddiejaoude's vision of EddieBotUI 😄.

[rossanodan]

Hi @rossanodan 😃, imo the final goal of EddieBotUI is to have a deployed website that displays all kinds of info about the community like bios, stats, badges, etc. We have some GitHub actions that collect data to the DB, so that info can be on this UI.

As for design for core features, I don't think we have it. We started the repository with React, CSS and Firebase Firestore, then we experimented with Semantic UI React and we were going to move to Bootstrap. But now there will be a DB switch I believe, and the community website uses Tailwind CSS. So I think we can re-think the stack choice and see what everyone else is also comfortable using 😃.

I'd also like to hear the opinion of anyone who is interested in contributing to a front-end project like this one, and @eddiejaoude's vision of EddieBotUI 😄.

@BOLT04 I updated the issue description. Please, take a look and tell us what you think :)

[BOLT04]

@rossanodan that's pretty cool 👍, one tweak I'd suggest is to instead of having a firebase folder, calling it dataAccess or data-access. The reason would be to abstract that implementation detail of it being Firebase, Mongo, a RESTful API, etc. The UI components shouldn't care where the data comes from.

I also have two notes about the design:

• on that design drawing (which is dope btw 👍), is that it's not completely clear where the components get their data from, since there is no arrow pointing to the Firebase box
• I'm assuming that folder for components are the re-usable components that can be used by any component, and then we have feature components - specific components for each use case/feature (in React's docs they have that). If that is correct, we could document that on the README so that is not an assumption on our design, and it becomes explicit in the documentation 😃.

[eddiejaoude]

Great explanation @BOLT04 💪 and great Issue with diagram too @rossanodan 😍

I am have not used React much, so I will go with what you both think is best. Let's avoid Redux though please.

Some of my thoughts though:

• We use TailwindCSS on the website, I think it would be good to use that as it made it easier for others to contribute (I think there is a PR for this already, I am still going through my GitHub notifications)
• I think I saw yarn mentioned in Discord, I think it would be good to stick to npm to keep the barrier to entry as low as possible
• If the preference is React that is fine, I think on the website I might use Vue instead of Angular (and I will move the BotMap away from Angular I think too, as it seems to put people off) - but I dont see this to be an issue
• The DB is currently Firebase (Firestore), but I really think we will move away from this to lower the barrier to entry for people. It makes it easier to run it locally, without an internet connection, without an account on firebase and also to write automated testing - not sure which DB yet, something like mongo/postgres/elastic, but we can discuss the DB we move to in another issue
• With design, could we do a low fidelity approach, to add value to the community sooner? I mean have it look good, but doesn't need to be perfect and it can be improved on - as I will take your guidance on this

Did I miss anything, let me know 🤓

[rossanodan]

About the drawing

Thanks @eddiejaoude and @BOLT04! I hope it's useful. It's just a draft, to explain my concepts and to support the conversation. A proper design can be included in some .md file in the repo, of course.

About components and feature-homepage (feature-components)

Since we're going to use Tailwind CSS, it does not make sense having the "shared components" folder. Components we will use will come from the CSS framework.

The feature-xxxxx is a folder that contains a big chuck of the project - see home page, 'user profile`, etc - that makes sense to have grouped in folders besides CSS and tests. For example

./feature-homepage
  homepage.js //component
  homepage.css
  homepage.test.js

These features components are used by the router to show pages. More details can be discussed while implementing. This is just a general idea about the structure and code organisation.

About the data source

I notice @eddiejaoude said something about moving away from Firebase. But this is not a problem for the front end. If the backend can expose an endpoint with some APIs.. well, we're fine 😄 We can simply fetch data via REST or GraphQL. @eddiejaoude please take a look at this.

About yarn and npm

yarn is faster than npm but it makes sense continuing with the latter to avoid confusion and to lower technical barriers for new contributors.

This is yarn ⬇️

[eddiejaoude]

this is not a problem for the front end. If the backend can expose an endpoint with some APIs.

Yes there would be an API that all our Apps / Bots talk to

[rossanodan]

Consider this as a preliminary design. I'm going to create a new issue to be addressed for creating an official guide to design and architecture of EddieBotUI.

@eddiejaoude @BOLT04