New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Huge refacto and updates ! #19
base: master
Are you sure you want to change the base?
Conversation
Styled Components | ||
</Label> | ||
Making design is often very painfull: How to organise classes ? How to make reusable components ? | ||
Should i use id ? Does my classe works with this component ? Where is my fu***** stylesheet ? ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I :)
src/Component/App.js
Outdated
Making design is often very painfull: How to organise classes ? How to make reusable components ? | ||
Should i use id ? Does my classe works with this component ? Where is my fu***** stylesheet ? ... | ||
<br /> | ||
<br /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe It will be better to use p
tags with style and not br
ones, WDYT ?
src/Component/App.js
Outdated
Styled components is a very popular and handy tools allowing you make | ||
designs with (wait for it...) Component. | ||
<br/> | ||
<br /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
</Fragment> | ||
|
||
|
||
export const BlackStrip = styled.div` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These styles should belong in ad edicated CSS file IMHO, to avoid very long files suche as this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ive play a lot with styled-components
. I was first not confortable at all with the concept but gosh, it's sooooo more maintainable and brings css into your codebase directly!
I've say in the homepage:
Making design is often very painfull: How to organise classes ? How to make reusable components ?
Should i use id ? Does my classe works with this component ? Where is my fu***** stylesheet ? ...
<br />
<br />
Styled components is a very popular and handy tools allowing you make
designs with (wait for it...) Component.
<br/>
<br />
You will love it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree too, if you still want to use styled-components
, consider to put these styled components in a dedicated file ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't agree. In many cases you may want to have a UI sort of file wich will contains some styled components for a given widget or anything, that's true. But here every component i have is directly attach to my domain. Why putting what is your domain outside of your domain ? you can still import those components import { BlackStrip } from './App'
and we stay closest as possible to the domain :). I don't think it's needed here to separate. The application is a single page so ne no need plural files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides, this repository is a bootstrapper, you will have to delete all this bootstrapping code. Here you just have to clean the App
and start over. If i separate it will 2 files to delete. And i really don't see the point to separate here ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about all of this, didn't we said we shouldn't bloat this app? Maybe just a part in the main readme telling people styled components are great and show an example of how you can make it work within this very project could be way better?
src/Component/App.test.js
Outdated
expect(items.length).toBe(4) | ||
}); | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why to have to charet return between each test ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SInce a function may contains "one chare return" inside there body, i find it more readable to separate them (i mean the functions) by two charet returns. Many people in the FP world are using this technic. It allows to put some charet return in functions as you want and separate this functions by two charret returns is a pleasure for the eye ^^
I liked the previous dog fetching example, it showed a common use case of resource fetching, state update and action reduction. Could be good to have such example here too ;)
Also, I think it'd be nice to introduce common app features, such as a router. We're currently refactoring the one of our frontend project using native history.pushState
api and plain regexp with named captures for route patterns. If you want to check it out, see PR 371 of our frontend project (you know which one it is ;p ).
Defining some pages could be a good example IMO.
Nice landing page tho :D !
@@ -0,0 +1,3 @@ | |||
# Debug the application actions and state into the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.env
file should not be versionned (use the .env.dist
file for that ;) ).
The app (no matter on which env) should use the .env
file to compile and run. Considering this, the .env
file should not be versionned and should be initialized from a deploy / init workflow (eg Makefile, CI).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why, since it's easier to not have the step of "Copy / paste" the env ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, by versionning the .env
we are winning:
- We don't need to copy / past the
.env.dist
file (just use a default.env
file, it becames the.env.dist
basicaly) - Create react app comes with a
.env.local
override system, allowing you to do the same thing as you mentionned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although overrides seems to be a quick win in the beginning, they end up in a mess in the mid / end of project development. As the .env
file is the one used by the app, it should not be versionned as its values depends on which env the app is used.
Having a plain .dist
file for each env (eg .env.dist
for dev, .env.preprod.dist
for preprod, .env.prod.dist
for prod) is way cleaner and avoids possible overrides errors / misconceptions.
Having to copy / paste the dist file is not a big deal IMO as it is part of project initialization (same as deps install). It's still a one-liner :
$ make .env install-deps # executes both `.env` and `install-deps` targets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does it mess up in the mid / end ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It gets harder to know what is the resolved value of a parameter for a given env when its value is split in multiple files. It's more readable and searchable to have a distinct env file per env with all the values in it.
Per se, the env file is dedicated to a single env, so versionning it binds it to multiple env and so is in contradiction with the aim of an env file.
@@ -11,7 +11,7 @@ | |||
src/**/*.css | |||
|
|||
# misc | |||
.env | |||
.env.local |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be reverted (.env should not be versionned ;) ).
@@ -1,8 +1,5 @@ | |||
.env: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be reverted too (see first comment ;) ).
</Fragment> | ||
|
||
|
||
export const BlackStrip = styled.div` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree too, if you still want to use styled-components
, consider to put these styled components in a dedicated file ;)
src/Effect/App.js
Outdated
|
||
// configureStore :: () -> Result Error Redux.Store | ||
export const configureStore = tryCatch(() => { | ||
const env = process.env.NODE_ENV || 'development' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
better fallback to prod
env by default IMO (safer). dev
env should be an opt-in config ;)
import ReactDOM from 'react-dom'; | ||
import './Style/Main.css'; | ||
import App from './Component/App'; | ||
import registerServiceWorker from './ServiceWorker'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this file be removed if not use anymore ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's removed no ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops my bad :p
return createStore(rootReducer) | ||
} | ||
|
||
const epicMiddleware = createEpicMiddleware() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be nice to describe dependencies injection here ( https://redux-observable.js.org/docs/api/createEpicMiddleware.html ).
All the utilities used by the epics (such as fetch) should be injected as deps here as it will ease the tests of epics ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, why not. We need to write documentation (probably in a wiki). We can then add a section about thoses dependencies
@NicolasNSSM i plan to make an entire example application, this repository must only be a starting point (like react does with create react app). For the router, i personnaly recomand nothing :.p. Since it depends on the navigation in your app, in some cases you may not want to use history at all or you may want to use react router ... I don't think it's a good idea to put a complete routing system inside this project |
@nicolasmure my bad, i've just seen that i have pre-install |
What about also making a git tag of the current project state ? |
On pourrait en profiter aussi pour mettre React Snapshot qui permet de prerender automatiquement toutes les pages publiques lors du build? |
@nicolasmure @NicolasNSSM @jaljo i'm wondering if we should not use : parcel instead of the complete "React create App" bootstrap. I've tried a bit to play with, it's realllllly simple ^^. @NicolasNSSM good point about An other point ... I've discover most wich is an other
Last but not least, i've discover two little babel plugins very very usefull: I would like to use them because it add sooooo much clarity in a Functional code flow ^^. Let me know what you think about all of that :) |
Rhalala ! |
Indeed it could be good to have two distinct branches (eg |
What do we do with this PR? |
Hello folks !
Je viens de démarrer une série de refacto / mise à jour de ce superbe repo, pour répondre au besoin que nous avons sur "C'est quoi faire du react à KNPLabs ?" ou encore "Je suis nouveaux, je peux avoir un éxemple d'app React ?" ou bien "J'adore le doliprane, fait moi mal à la tête !".
L'idée principal est d'utiliser ce repo afin de proposer une architecture clair et mise à jour pour nos application React FRP (functional and reactive). Bien evidemment, personne n'est obligée d'utiliser ce repo pour leurs projets react (un simple
create-react-app
de facebook peut-être largement suffisant !). Cependant si vous chercher un point d'entrée pour une application plutôt bien grosse et que vous voulez vous mettre au "FRP" (Functional Reactive Programming) et bien ce repo est là pour ça :).Qu'est-ce qu'il à bricoler encore le Jagon ?
1. Une nouvelle archi
Je propose cette architecture:
2. Une page d'accueil qu'elle est pas mal noir et blanc sexy
Un peu de vocabulaire
Pour bien comprendre l'archi et tout le tintouin voici quelque notions expliqué vite fait et plutôt mal:
Pure / Impure
Une fonction est dite Pure lorsque qu'elle ne produit aucun effet secondaire. Un éxemple:
const add = (x, y) => x + y
. Attention toute mutations est considéré comme impure (ex:const pushCoucou = arr => arr.push('coucou')
iciarr
est muté et contient après l'appel'coucou'
, la fonction est donc impure!)Une fonction est dite impure lorsqu'elle contient au moins un petit riquiqui effet secondaire:
const currentHref = () => window.location.href
Impure, carwindow.location.href
est mutable!const getUser = () => fetch('/users')
Impure, car on ne peut pas prédire le résultat de la requète httpLes Effects
à chaque fois que vous rencontrer une fonction impure l'idée et de mettre ça dans le répertoire "Effect". Généralement la plupart de vos fonctions impure serons vos Epics, mais dans certains cas, un Observable est plutôt complétement overkill (comme lire la location). Pour ceci j'ai préinstallé crocks qui permet d'utiliser des "ADT" (technique répandu est fiable pour gérer des side effect).
Du coup un éxemple avec
location.href
serait:À vous de choisir ce qui vous convient le mieux pour votre projet, aucune obligation d'utiliser crocks bien evidemment. Mais garder en tête qu'un effet est est simple fonction qui ne prend pas d'argument et fait de la magie:
Component et State
Tout ce qui est dans
Component
ainsi que dansState
doit obligatoirment être pure. Quelques exceptions faite pour les composant (dispatch
etevent
sont autorisé bin sur).Graçe à React 16.8 plus besoin de classe pour vos
lifecycle event
:Voili voilou, j'espère que ça vas vous plaire :). Hesitez pas à commenter à fond la caisse ! Des bisous !