Frontend libs

[bhoomij]

As per finalised tech stack frontend will be "React using JavaScript (not TypeScript) and CSS (not Sass)"

Would like to discuss on which packages/libraries are best suited with react echo system ?

Will use any boilerplate ?

1. create-react-app
2. https://github.com/react-boilerplate/react-boilerplate

These two almost provides readymade support for transpiring and bundling and makes app production ready from day one.

Other useful packages I would like to add:

1. Reselect : Provides memoization and avoids wasted renders. More
2. Redux: App state management
3. Redux-saga : For asynchronous call, uses generators and provides some good features like take_latest. Check Redux-saga and redux-thunk-vs-redux-saga
4. React-intl: Refer Internationalize the Chapter Application #21

Would like to hear community thoughts and experience with this and any other useful packages, we can include in frontend tech stack

[Utkarshbhimte]

Given the requirement, I think a server side rendered app would be more beneficial for SEO

I propose using nextjs instead of cra

[Zeko369]

@Utkarshbhimte We already said that Next will be used, so create next app?

[Zeko369]

Also IMO if we use Redux we should use ReduxThunk because it's easier to get into for people who havent working with it in the past, and is generally more widely used lib

[pabloHoc]

Are we going to use some UI library? If so, I'd like to propose Chakra-UI, it's a really simple and composable component library crafted with accesibility in mind and uses emotion and Styled System. It's also OS.

[aeganaden]

For UI Library, i would like to suggest React Ant Design. It has a rich set of components ready to be used, and unlike other component library its UI is sorta new to other users.

[isubasinghe]

I think redux is a must for any non trivial application with state. It just makes doing React state management much much easier.

[ghost]

Thoughts on using formik & yup for form validation? Both are well documented / supported libraries. It helps immensely to standardize validation as well.

For api calls, I would suggest axios.

[MirzaChilman]

We already agreed to use next.js you can see the discuss here

@isubasinghe as for state management, we still haven't figured it out whether to use it or not, as we are still blind here

[sinharaksh1t]

If we do consider using Redux for application state management, then it's worth giving redux-query a read. It's a seamless way to manage the network state into your Redux store.
Also, any API calls made through redux-query goes into your Redux state along with the network state of the call. Rendering it pretty useful when showing different UI feedbacks if the API call were to fail, is in-flight or succeed with delay.

[MirzaChilman]

Never heard of redux-query, anyway probably we should list what kind of libs that we are going to use, at least we can discuss the pros and cons of each libs

[Wizyma]

Redux-saga is really hard to grasp, specially for people not that experienced in JavaScript...
There is others tools to use.
In my company we use it for our main app, it works well no doubt, but only few can really maintain it and understand it.
When it comes to async calls, it is way overkill to use redux saga if it isnt for critical reasons.

[Wizyma]

@bhoomij for i18n there is i18next too.
It is mature, a lot of support and a gold documentation.

[keeth]

I've had a lot of success with Material UI, however that would mean ditching CSS for JSS.

[Wizyma]

and for others libs:
styled-components for styling
react-redux for global state management no doubt
material-ui as an UI lib ? customizable and quite powerfull
testing-lib for testing components
ramda for utils and FP

[keeth]

If Redux is used carefully and appropriately it can be good but it can also get messy, I've seen large project turn into spaghetti by relying too much on Redux, especially around keeping the DB/server state in sync with the client state. GraphQL solved this for me but I know we're not doing that for v1 of Chapter. Worth looking at all the alternatives. Hooks, Context, unstated, URL state, etc.

+1 for Ramda, it's so great.

[keeth]

I assume most people use Moment for date/time calculations. I've recently started using date-fns and quite like it.

[mquadrant]

I assume most people use Moment for date/time calculations. I've recently started using date-fns and quite like it.

date-fns is referable, personally. You could imagine the space moment import eats up.

[nsharma1396]

We can consider using Immer.js. It can help to work with immutable states in a very clean and easy way. Helps a lot to avoid accidental state mutations and makes the app more predictable I believe. It's quite good for managing complex state objects or redux state and is very easy to learn and use.

[H-Plus-Time]

linaria is a drop-in replacement for styled-components, it tends to produce lighter JS bundles (in exchange for statically generated css) and more performant instances (setting CSS variables is exceedingly fast).

[pabloHoc]

I think Ramda is too much for the moment, since introduces a complexity for those that are not used to FP. The idea is to keep this as simple as posible.
The stack decided was CSS for styling, so that leaves out styled-components and most UI libraries (including Chackra UI, my bad).

[tomByrer]

Since React requirement is locked down, may I suggest Gatsby as a more turn-key solution?

Gatsby

• well funded with a large team
• solid MDX support (Markdown + React component; more newbie friendly than plain React)
• 50+ integrations with other CMSes, databases, 1-click hosting, etc.
• Constant updates

While Gatsby has a vs Next page, let me add my observation:

Next

• Smaller, more focused team
• feels more streamlined to me
• More cautious about releases

There is "Create React App", are there other React bootstraps we should look into?

---

Disclosure, Somehow I was added to Gatsby organization. Might be my mis-click, someone like me?? I think I might have submitted 1-2 doc PR fixes, but I'm not really that involved with the project.

[viniarruda]

and for others libs:
styled-components for styling
react-redux for global state management no doubt
material-ui as an UI lib ? customizable and quite powerfull
testing-lib for testing components
ramda for utils and FP

I use the Material Ui in a large scale software and I had a lot problem to customize the components, I prefer the ant design for use here

[corlaez]

I hear people advising some kind of state management solution but I also share the opinion of avoiding redux at all costs.

However we would need an alternative. Let me present you https://overmindjs.org

Overmind works amazing with React as a hook or HOC. You can write regular mutation code (so no immer needed) it has amazing async or promise support (so no need of thunk sagas etc) and it's a single state tree that you can define however you want.

The experience is amazing with typescript but I read we decided not to use it. Anyways Overmind can be used with Javascript anyways.

It is really easy to use and it now has statecharts support. If you feel we need a better option of state management defibetly check this out.

[rinajhinjhina]

We use Material UI and while I like it very much, it is very opinionated and uses JSS which I think goes against the preferences for this project. I would prefer to keep styling to CSS or SCSS. A UI library would definitely help though. Are there any suggestions other than Material UI?

An alternative to Moment other than date-fns can also be DayJS.

I also really like react-i18next as it makes internationalization a breeze.

[MirzaChilman]

@corlaez I strongly agree with him, because if we structure our app properly then actually we don't need redux, I've seen project using redux and confusing for new comer, and slow down development, as new comer spend more time understanding the redux instead developing the features

[ThomasRoest]

I've worked with React for a few years, these are my recommendations:

Styled-components: Makes writing css so much easier, never having to think about global stuff, naming classes, unused css etc.

MobX: My preferred state management solution, if just React state/Context is not sufficient. Much easier to work with than redux.

Formik: Tried it once and have not looked back. Makes handling forms in react so much nicer

UI-lib: Didn't have good experiences with Material UI, I would prefer react-bootstrap or any other simple lib for buttons, modals etc.

Cypress: for e2e testing.

[chaotic-stump]

Whatever UI library is chosen, it should be something lightweight.

I’m a fan of Skeleton, especially since this project is CSS only. It’s 300 lines of CSS that you can customize without needing !important tags or other shenanigans.

Anything with a grid system is too much. Now that CSSgrid is a thing and there are graceful fallbacks using the @supports tag for the small percentage of browsers that won’t support it.

Also, the more components to build, the more chances people will have to learn.

[mquadrant]

In as much we would be writing the CSS without any library. Styled component is a very good plugin that would help writing the style of any component in Js. Every reusable component should have its styles embedded in the Jsx file not an external file , this will ensure that we don't bother too much on maintaining extra style sheets especially when the project is becoming large.

[rinajhinjhina]

@mquadrant I agree, and styled-component compiles down to CSS anyway, so I don't see much downsides there

[nulfrost]

@mohanwer I just found React Hook Form recently and I think it would be a lot easier to work with than formik. It has its own validation out of the box or you can use yup.

[SandipNirmal]

What about using Semantic-UI with Styled component. Or we can also use ionic which has recently added React components. https://ionicframework.com/blog/announcing-ionic-react/.
Along with Hooks, Redux, Redux-saga, Formik.

[kognise]

All of these are great suggestions, but I feel like we shouldn't try to solve problems we don't already have - if we need a library we can find it.

[PrestonElliott]

I think for MVP we should stick to React, React-Bootstrap, and CSS. We can add additional libraries and functionality for future releases, but MVP should be achievable in the near future!

We could implement container components to create event cards, add test users, and be able to demo the app.

After MVP, it'd be beneficial to refactor into React-Redux as the app scales.

[francocorreasosa]

TBH I think this can be easily solved with Next.js (no extra state management, SSR) and Bootstrap or Chakra UI.

[Wizyma]

Everyone talking about bootstrap, but nobody talks about design system , the rebass lib ?

And i saw some comment saying they had bad experience with material-ui please share why !
Just saying no "i didnt like it" makes no sense!

I'll Start: i am using material ui since V1 in my company wich is one of the biggest french company, with more than 800 software engineer.

In the begining material ui was not friendly at all, v1 and v2 had a lot of issues, but now the community and the core members did a lot of work to make things more maintenable,
V3 was a huge step forward, with an api who was more clear, and they stayed in the same track with v4 who is killing it.

But still i am not a huge a fan of the lib JSS they are using but except for that, perfs are now good, the Doc is gold, they implemented design system, the community is huge and reactive!

When we talks about libs to use in this kind of project, i think we have to ask ourselfs the impacts and why it would make life of everyone easier.

Personnaly seeing react-boostrap feels like seeing people asking for JQuery 😱
But thats my personnal opinion 😬 !

But for the rest share your experiences with some pro and cons, that will make the debate more open to discuss about it.

Thanks !

[MirzaChilman]

I hope this helps, but I'm gonna list out every libs here that already been mentioned above, and we can decide it later which one will be used, as for this moment we are still blind so having people discussing which librs better than others, aren't beneficial for now (IMHO)

Design System

• Material ui
• Reactstrap
• Ant design
• Chakra ui
  please be mind that we are just gonna using CSS, which some of UI libraries above are not meet the requirements, but we're gonna talk about this later

State Managements:

• Redux
• Mobx
• Immer.js

Translation

• React i18n

Date:

• Date-fns
• DayJs

Forms:

• Formik

Again we are pretty much blind here, so thinking of what libs should be used, isn't the priority right now, if someone can come up with a mock up based on the existing schema and routes, I think it will be much helpful to think what kind of libs we are going to use

[QuincyLarson]

All of these are great suggestions, but I feel like we shouldn't try to solve problems we don't already have - if we need a library we can find it.

100%. But we need to keep maintainability in mind. How hard is it for a potential contributor to get up-to-speed and able to update the codebase?

freeCodeCamp started out using a lot of tools, and over the years, we've stripped most of them out because they made it harder for people to contribute to the codebase.

Also, some of the tools listed on this thread are likely to become deprecated in the coming years. This is hard to predict. But it can lead to a lot of additional maintenance work.

This is a long-term project that organizations will use for decades to come.

The initial time spent building this project may only be 20% of the total work. The rest will be spent doing maintenance, so we should be sure to optimize for that.

[wuilliam321]

Agreed, from zero to hero. xD from simlpe to complex. We don't need a big stack at the begining.

[vkWeb]

@QuincyLarson Yes. Perfect! That's what I was thinking.

I would recommend starting with a basic stack as already mentioned on README and then we can always add more tools in the future. Let's kick off this project asap instead of getting confused with stack & design. :)

[abidRahim]

For UI Library, i would like to suggest React Ant Design. It has a rich set of components ready to be used, and unlike other component library its UI is sorta new to other users.

React Ant Design may have issues with i18n (Internationalization) and localization for future prospects. I've had hard time figuring things out with it, if anybody has a way around it, I would like to hear it.

[keeth]

yes, everyone loves sharing their fav stack and tools, and their horror stories ha ha (me included)

i defer to the coding education experts on this! :)

excited to break ground. go team!

[allella]

#76 is asking about testing. Should that conversation remain independent of this one, or shall we merge them?

[vkWeb]

@allella Let it be a different issue.

[Lobarr]

I think it should be a different issue as testing applies to the backend too.

[shirakaba]

We have been discussing in #20 how to build the mobile client. I've been championing React Native, which has been met with some support. This opens up the opportunity to make the mobile client from the same codebase using React Native Web (which transpiles abstract universal UI elements like <View> and <Text> to equivalent React DOM elements) rather than directly using React DOM (which can't be code-shared with other platforms). I detailed the merits of RNW in detail in this comment on issue #20 , but in short: RN and RNW have worked out very well for Twitter.

If RNW were chosen over React DOM, this would have an impact on the selection of frontend libs that we may consider.

• It seems that Next.js supports React Native Web.
• React Navigation is the best-supported option for navigation on React Native Web.
• React Native cannot consume CSS files directly; it is idiomatic to declare CSS styles in JS instead. React Native Web can consume CSS files, but that would mean giving up on code-sharing styles between the web app and the mobile apps. There is a tool called CSS to React Native, but I imagine it comes with all sorts of fun surprises.
• There are answers for Material UI on RN, though I don't know how reliably they translate to RNW (haven't checked). They may be fine.
• Any libs that are not coupled to a specific React renderer would work fine on both RN and RNW. So Redux is fine, for example. Any vanilla JS libs to be shared with RN would need to be free of any dependencies on the window object (and more specifically, browser-specific dependencies).

The React Native Web library itself provides a lot of functionality (as it has to implement all of React Native), so there are some handy libs in there. It also opens up the ecosystem of React Native libraries to some extent, like react-native-reanimated, an animation/gesture-handling library.

[keeth]

@shirakaba I love this idea. I'm taking a similar approach with one of my projects at work and I think it makes a lot of sense. One codebase to rule them all! :)

[QuincyLarson]

@shirakaba We can consider mobile UI options once we've built the web version for our MVP. I think React makes the most sense here so I'm going to go ahead and close this issue.

[allella]

RE: UI frameworks

#114 (part of the roadmap) holds some of the UI framework conversation, along with #121 and this issue.

Also, Quincy's vote was for using a UI framework to start and not custom-building from the start.

we can just grab a framework off the shelf and use it for our MVP, then write our own custom, more-optimized UI code later.

[shirakaba]

@quincy

We can consider mobile UI options once we've built the web version for our MVP. I think React makes the most sense here so I'm going to go ahead and close this issue.

React Native Web and React DOM are both “React”; just that the former transpiles to React DOM while the latter is React DOM. For clarification, are you talking about going ahead with direct use of React DOM?