Closed rossanodan closed 4 years ago
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.
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 😄.
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 :)
@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:
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 😃. 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:
yarn
mentioned in Discord, I think it would be good to stick to npm
to keep the barrier to entry as low as possibleDid I miss anything, let me know 🤓
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.
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.
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.
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
⬇️
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
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
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.
@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.