ecronix/react-most-wanted

Suggestion to make a clean PWA project without binding to firebase.

Closed this issue · 32 comments

I really like your project architecture, but I need it without Firebase. I can’t cut Firebase myself ...
Where the start page would be an authorization page that would accept any data and be authorized with them, the menu items would be a navigation to the demo pages.
Perhaps someone already implemented it based on your project, I would not mind linking to such an implementation if it were

ideally, I see it like for example this, but with your design and architecture, where the start page is the authorization page, if you have not been previously logged in using the flag in localstorage

please tell me how it is possible to implement the first opening from my login page, where I can log in when entering any mail and password, so that the authorization flag is set so that I can then get to the dashboard page with hello wolrd filling, my points menu where when I click on them I would get to the corresponding pages with empty content?

@UseMuse You can try to cut out Firebase but it's code will still stay inside. Also all that logic you want me to answer you is very strong connected to the firebase libraries. I would recommend to use another boilerplate if you don't want to use firebase. Because this would make you then more problems then solutions.

I was thinking of to make a pre Firebade version in witch you can just plugin Firebase or OAuth2 or what ever you want. Like a pure basic setup for routing, i18n, Landing page separation for better performance. But in the end those parts are not so hard to do. This is realy a user specific boilerplate. If there where enough ppl out there that would like to have a clear boilerplate without Firebase pls tell them to like this comment or to comment here and I will see if I can find time to do it. Also all PRs are welcome. We can have that project also here in this monorepo because a lot of parts are related.

@TarikHuber I started the implementation, I had to change the rmw-shell components, I added all the data to the project and changed some of them, I copied some data from the firekit to the project, and put all these changed data in one project, now I settled on the fact that he starts up and asks to log in. I’m thinking about how to implement authorization architecturally. I started react & redux not so long ago, I would be very grateful if you had a look at the project, and perhaps suggested the resulting architecture, and how best to implement authorization. Where authorization will be, enter mail and password and click to authorize with any input data, on the next visit to the site, if there is an authorization token then show the dashboard, these are the plans, I will be glad if you help.

project link https://github.com/UseMuse/react-most-wanted-clean, project launched : npm i, npm run start

I think it’s possible to “clean” it more

Hi @UseMuse I think that it would make more sense to have a clean package and build apon it the firebase package. A lot of parts like the components, FormFields etc. can be used as they are in both. So I would not copy this project in another and have a fork. That would produce more problems than solutions. If you want I can start a package in this repo and we can work together on the clean version. For the auth I wuld just provide the function isAuthenticated and getAuth. The rest should always be project base. We can ofcouse have a demo login with email and pass but that should be replaced very easy. I can then keep an eye on it so that Firebase can be integrated into it. What do you think about that? I was anyway planing to start with it these days. Sorry for the lock. One of my shildren was playing with the phone 😆

@TarikHuber I agree with you. Let's get started on a clean version.

@TarikHuber I suggest based on the create-react-app template, I suggest placing components, containers and other src folders in the node_modules folder: src-> node_modules -> components, so as not to prescribe file attachment during import, for example, this approach allows you to write components / Drawer, instead of ../../components/Drawer and so on from anywhere in src, while preserving the usual import method: ../../components/Drawe. Do I understand correctly that in the current rmw architecture, containers are smart components, and components from the components folder are dumb? what about the hoc components - place in the hoc folder, start the names with with? When to use redux and when to react context? My opinion, for a clean template, the less third-party dependencies, the better. For PWA, I suggest using google workbox with workbox-build - this is the best solution for pwa. Add pwa precache for working web app in offline. How about for a clean version use jwt as a service for authorization. As for pwa, as I think it would be super to have an example of push notifications, with a subscription to them and unsubscribing, this can be placed on the user’s page. To make a page for demonstrating the operation of push web notifications, on which to place the form, when entering text in which the text entered, provided that the current user has subscribed to the notifications and gave access to them, would receive this notification with the text entered in the form. When you click on the "unsubscribe from notifications" button, when entering in the form of text and sending, notifications will not drop.
Also for pwa, you can make a page (for example todos) demonstrating how to work with local site data offline,
embed your pull to refresh, where when swiping down, being on this todos page, being online, upload / update todos data from https://jsonplaceholder.typicode.com/ to the local database (idb) if users are offline and todos data was previously loaded, then when swiping down, load data from idb. Add a flag to the site showing online or offline. Also functionalities: localization, dark theme, theme color change, cool menu from rmw, dialogs, pwa installation and version update notification,put in a clean theme.
outline ideas :)

Greate ideas. We should just start ad see what happesn ;) my favorite appriach.
First I woul realy like to have a totaly clean setup with basic routing and i18n. We can call that app-shell. Building appond that we can create one called mui-shell witch would be the app-shell with Material-UI designs. The rms-shell would be both of them improved with firebase. If someone want's to use Bootstrap for example he can start with app-shell and don't bother with Material-UI.

What we need to have in mind is the performacne and code sharing. For performacne app-shell nededs code splitting and also the landing page needs to be separated from the app. Only that way big apps can have a good lighthouse score.

I will try to start asap. I would not move any code into node_modules. cwb that I use for the libraries has an alias config with. That the demo-s for example can use import like if they come from node_modules and also the npm link functionality can be used to test components across packages.

This can only be an oppinioned project. There is no best practice in the react world. So let's hope we make good work and devs like our decissions.

I also thought about creating such a universal shell so that I could use it under different designs, but it seemed to me to be a bit detailed, but I like it

And PW features should be optional and for the Service Worker we need to rely on Crate React App. I would leave that as base.

Ooo those submodules. Hat it when it happens. There should now be a clear starter on witch we can work on.

@TarikHuber hi, how to run submodule?

Go insite the packages/base-shell and just run npm start

@TarikHuber add a TODO CRUD page as an example using, for example, the API service https://jsonplaceholder.typicode.com/
using IndexedDB. No style components. This will serve as an example of how to work with the API and IndexedDb, and demonstrate the work of SW offline, what do you think?

Maybe we should wait with such complex examples untill we have the shell done. There is still a lot of work to do.

routing by the authorization role, for example, if you are authorized in the "admin" role, all routes are available to you, if in the "user" role, then only valid routes for the user. It turns out the routes will be divided into private (accessible only by authorized) and public (accessible to all) and private with a role (authorized in a role)

I think that we should leave the authorization to each project. Especially in the bas-shell we should realy provide only the basic shell for a project and not more. We can make a bootstrap-shell where we can have more UI and such stuff with auth. The base-shell schould suite 90% of all use cases.

@TarikHuber I agree, I just throw ideas that seem interesting to me. What can I do for base-shell?

@UseMuse you could make some basic Menu for the routing. But make sure you send it only trough the demo part. There should be no UI in the base-shell package itself. You should always send your UI inside. I'm working on a Container Component witch you can set in the configs so it will wrapp the whole app. You can use that for custom providers or other wrappers like Analytics, Toasts etc.

@TarikHuber I added an LP page and got an error:
Warning: Functions are not valid as a React child. This may happen if you return a Component instead of from render. Or maybe you meant to call this function rather than return it.
     in Suspense (at App.js: 21)
     in App (at src / index.js: 8)
     in Demo (at src / index.js: 12)

look here https://github.com/UseMuse/react-most-wanted

in short,
UseMuse@aa99f2a

@TarikHuber I did not see the option to add injectIntl to the App and other related parameters when I added localization

Hi @UseMuse I just made similar implementations and it worked ou. Check it out. I also enabled the PrivateRoute so you can also simulate a login page and auth behaviour.

Hi @TarikHuber, as I understand it, in order to implement the authorization page and the authorization itself, do I need to do one more demo or implement it in the same demo?

Hi @UseMuse you can do it in the demo folder of base-shell. Just don't add anything of the auth to the src folder

@TarikHuber added authorization to the demo, but after authorization, the transition to private route - home is not possible, since you asked me not to add anything from authorization to the bas-shell, I just displayed the result of forwarding authorization data in PrivateRoute in the console

Hi @UseMuse there was a small bug inside. Now it works. I also added a logout button. I will as next check out how to implement react-intl without having it in the LandingPage. It is to havy for that because of performance reasons. The LandingPage also deosn't need to be lazy loaded. That makes the first render even slower. I wou want you can add some linkt to the menu so we can test the navigation. The menu should not rerender on navigation change.

Also @UseMuse thx for doing this with me. I need for such work someone like you who can help me with the details. I apprittiate that a lot! Thx

@TarikHuber my contribution is small, I will try to help than I can

I'm considering to make the base-shell and material-ui-shell without redux. We need there only something to store the menu and intl data and both are just basic and simple ones. Redux couls still be optional by just changing the config. An opt-in for the redux would be more open then a opt-out.

We are working on it so will close this issue.