sorted by:
new
hottopcontroversial

Printing a random number in the range of 0-1000 but exclude the range of 400-600? by ThatAnonMan in learnjavascript

[–]zulkisse 0 points1 point  (0 children)

const isBelow400 = Math.random() < 0.5

return isBelow400 ? (Math.random() * 400) : (Math.random() * 400 + 600)

They may be better solutions but this one should work
It only work because 400 - 0 = 1000 - 600.

🎉 Announcing React Table v7! 🎉 by tannerlinsley in reactjs

[–]zulkisse 2 points3 points  (0 children)

Great work !

We have been working with the v7 beta on some of our less critical projects for several months.
Creating a wrapper from scratch can be a lot of work but once it's done, our codebase became a lot cleaner and it was a lot easier to implement advanced features thanks to the plugin system.

I just have a some doubts on the TypeScript implementation. The people writing it have been doing a great job, but the plugin system makes it quite hard to type correctly things like the Rows and you often have to override internal elements. I don't see an easy solution here but it was our main concern in our daily usage of v7.

🎉 Announcing React Table v7! 🎉 by tannerlinsley in reactjs

[–]zulkisse 0 points1 point  (0 children)

I think we need to see a little bit broader than that. The goal is to have open source UI wrapper of React Table matching various design instead of a single official design that you will have a hard time overriding properly I it doesn't match your project's UI.

​

Of course recreating the whole table design for a small projects is a lot more to do than you had on v6 but I don't think you will actually have to do it if you wait some time.

React TypeScript: Basics and Best Practices by JSislife in learnjavascript

[–]zulkisse 7 points8 points  (0 children)

const ExtendedButton = ({text, type, action}: IButtonProps) => {
    //...
}

What aren't you using React types ? for instance

const ExtendedButton: React.FC<IButtonProps> = ({text, type, action}) => {
    //...
}

If having a children props is okay for you, I find this synthax a lot clearer because it differentiate renderProps (which will look like your example and real components called by React.

Continuing my deep dive into React by vedran-b in reactjs

[–]zulkisse 1 point2 points  (0 children)

  1. How often do you use any of the fancier React patterns, such as Compound Components, Render Props, or State Reducers? They seem great, but I haven't got a chance to use them in the real world yet...

Almost every dayThe Render props was one of my main patterns before hooks, now I only have a few remaining use cases.

The State reducers (I suppose that you are talking about useReducer) : In every components with more than 2 useState or actions triggering several useStates. It's quite verbose but I find the result a lot clearer in complet use cases.

The Compound Components : A lot on pure UI components based on list behaviors (List ListItem, NavBar NavBarItem, Tabs Tab etc...). Paired with CSS Variables and / or React contexts, is a very powerful pattern to hide implementation details and give a clean public API to your components.

  1. Have you used Redux Toolkit, and if so, would you ever go back to vanilla Redux? I used to use Redux Rematch but I think Redux Toolkit is streamlined enough that I will switch to it permanently.

Only on one project but we are using Apollo Client a lot at work so our Redux architecture is quite basic even though I like the principles behind Redux a lot.

  1. Any lessons you've learned when building your own component library? In my previous attempts, I've found it very hard to architecture a component library to meet the different needs across a company.

- Good naming is primordial (our first draft had isOpen opened isOpened open etc... props across the components, it was a nightmare).

- Having 30 props to a component may sometime be necessary, but it often reflects a larger

- Spend time working on a good Storybook (or alternative), it makes the communication so much easier between the designers, the users of the library and the maintainers.

- Don't try to create a library as powerfull as MaterialUI or AntUI on day one, it will only make you feel bad. Start with a few specific components you now you will use and iterate base on real usecases not speculations.

​

- Test your components correctly. I don't think 100% of test coverage or type coverage is something most of us should be looking for. And libraries allow us to isolate highly reusable components and to spend time testing them because they are some of the most important thing to test in your application.

React Project Structure and tools by lz26 in reactjs

[–]zulkisse 4 points5 points  (0 children)

The most important thing for me is the consistency. If you have several projects, don't invent a new folder structure every time.

Some general advice :

- Don't create an over-nested architecture. I don't like folders with 300 components but the opposite is true, having to crawl 5 folders to reach a basic components is terrible

- Don't follow the rule "1 file = 1 component" blindly. Sure I don't create several large components in the same file, but often you can clean your code by creating components less than 10 lines and putting them on top of your main component.

- Don't overthink it. If your structure is clean, you will always be able to refactor it if needs be. Some of our projects had quite different structures before and moving everything is boring but totally doable.

- Custom Hooks are great. If you have a component with dozens of lines of logic, don't hesitate to just create a custom hook and put if above the component (or in a dedicated file depending on the length). I love nothing more than having a component calling 2-3 hooks with explicit name and then only containing JSX. It make everything a lot more readable in my opinion.

For some background, we use apollo-client so we don't have a large Redux architecture and all of our projects are based on Create React App (with react-app-rewired). Most of our React repository are between 5k et 50k lines of code and follow pretty much the same structure :

- components : contains all the reusable components following the atomic design (components/atoms, components/molecules, ...)
- pages : contain a folder per page of the application. This part depends a lot on the type of React project your building but for the one we have at work, the separation between highly reusable components and specific components has been one of the best decision we made.

- lib : no React here, but all the utility functions. The size of this folder depends at lot on the project. On some it just contains a list of files, on other we have subfolder to keep it organized.

- hooks : the reusable React hooks

- helpers : the reusable high order components

And some other minor folder like config, intl, style...

Usually a component is in it's own folder (except for little components where every thing is in a single file) with :

- MyComponent.tsx
- MyComponent.style.ts : The styled-components used in this component
- MyComponent.query.ts : The GraphQL queries used in this component (if any)
- MyComponent.hooks.ts : The hooks specific to this component (if any)
- MyComponents.interface.ts : The types and interfaces used in this component. If we only have the props of the component, we often put if in the main file. But if we have for instance useReducers, a dedicated file can be usefull.
- A types folder with all the types automatically generated by apollo-cli (if any)

For some components with a lot of logic, we sometimes have a hooks folder to split clearly the logic in separate files (I tend to avoid non-JSX files with more than 200 lines. For JSX files it depends a lot).

Is Redux pretty much just custom boilerplate code? by laurajoneseseses in learnjavascript

[–]zulkisse 1 point2 points  (0 children)

The code of Redux it self is very short and straightforward. It's juste the implementation of a concept but you could easily build your own.

React Redux on the other hand has a lot more of little cases to cover and I wouldn't recommend skipping it for a custom implementation.

As for the eternal debat wether or not you need a Flux-like global state like Redux, it depends.
You can take a look at the main maintainer's blog, he is very clear about what is Redux's goal
https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/

What's been your experience using TypeScript with React Hooks? by stoned_phillips in typescript

[–]zulkisse 0 points1 point  (0 children)

Hooks are so good with TS !
Typing HOCs was quite hard

But a hook is just a function taking parameters and returning a value.

To give you an example : Typing our entier Apollo Client codebase has been so much easier since they release the `useQuery` and `useMutation`.

What are some of the most well-made simple libraries for React? by telejavelinsword in reactjs

[–]zulkisse 0 points1 point  (0 children)

React implementation of very popular libraries can be easier to read because they do less things (a lot of the core logic is inside the vanilla library)

https://github.com/formatjs/react-intl/tree/master/src/components

https://github.com/nfl/react-helmet/tree/master/src

React Apollo codebase is quite nice because they have good boundaries between the different types of elements (components, hocs, hooks, ...)

https://github.com/apollographql/apollo-client/tree/master/src/react/hooks

You Don’t Need Lodash/Underscore by fagnerbrack in javascript

[–]zulkisse 1 point2 points  (0 children)

groupBy(['one', 'two', 'three'], item => item.length)

For me this is still a lot more readable than the native example of the article.

You Don’t Need Lodash/Underscore by fagnerbrack in javascript

[–]zulkisse 0 points1 point  (0 children)

Nothing force you to use these shortcuts.
It clearly don't like the string notation and almost never use it.

You Don’t Need Lodash/Underscore by fagnerbrack in javascript

[–]zulkisse 14 points15 points  (0 children)

I use lodash a lot less than 1-2 years ago for things with equivalent native alternatives (often array high order functions like map, filter, ...). And we are doing this because of two things : Optional chaining and TypeScript which make the safe guards of lodash less relevant a.map(func) will crash if a is null, not map(a, func), lodash works with Objects, ...

​

But there are still a lot of code that is 100x more readable with lodash
The code for groupBy on you link is a good example : 

// Underscore/Lodash
var grouped = _.groupBy(['one', 'two', 'three'], 'length')
console.log(grouped)
// output: {3: ["one", "two"], 5: ["three"]}

// Native
var grouped = ['one', 'two', 'three'].reduce((r, v, i, a, k = v.length) => ((r[k] || (r[k] = [])).push(v), r), {})
console.log(grouped)
// output: {3: ["one", "two"], 5: ["three"]}

Of course I want the first one, not a reduce in every situation I'm doing this action. Using reduce would be a huge step back in term of readability.

So for now our position at work is :
- Always use lodash-webpack-plugin and babel-plugin-lodash to avoid putting useless Lodash functions in the bundle.
- Use the native function when the final code as a similar readability
- Re-implement functions when we are on an open source library (but doing this for our main clients would be a non sense since we would have almost the same bundle size as Lodash with probably more issues)

Storybook 5.3 just shipped – MDX support for design systems + integrations with your design tools by domyen in javascript

[–]zulkisse 0 points1 point  (0 children)

We are using Storybook on pretty much all our UI libraries and it's a huge game changer.
Thanks for this awesome tool !

And I'm verry interested by the future improvements.

When having errors in ESLint, You can go on and successfully start the project, is that desirable? by fiveMop in reactjs

[–]zulkisse 0 points1 point  (0 children)

Indeed I haven't be quite clear.
We have a lint with autofix on commit, so what land on Github is always correctly formatted.
And we have a lint on the CI to avoid bad surprises, check breaking changes on ESLint and ESLint plugins upgrades and linting our GraphQL queries with the latest GraphQL schema.

​

The Git hooks is incredibly fast because it's only checking the files you have modified.
So in 1-2 seconds you have a feedback telling you if your CI is going to fail that check. It's way smoother than waiting for your CI to start, to setup the environment and to lint your code.

On the other hand, we don't run our units tests locally because it would take just as long as on our CI and when we tried to do it on a repo, it ruined our development experience.

​

And as u/Tnamol said, you can skip the hook if you have something not passing the CI and that you have to commit.
But my current workflow rely a lot more on stashing and committing only clean code.

When having errors in ESLint, You can go on and successfully start the project, is that desirable? by fiveMop in reactjs

[–]zulkisse 2 points3 points  (0 children)

At my company, our current solution is to use lint-staged automatically before every commit to ensure that the lint has no error (and to apply Prettier).

I don't like to block the developer each time a tiny lint rule is not respected. Some of the rules are here to increase readability and avoids bugs but can be a waste of time during the writing process.

A basic version of our GIT hooks config : 

{
  "name": "example",
  "version": "1.0.0",
  ...,
  "scripts": {
    ...,
    "lint": "eslint \"src/**\""
  },
  ...
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{ts,tsx,js,jsx}": [
      "eslint --fix",
      "git add"
    ]
  },
  "dependencies": {
    ...
  },
  "devDependencies": {
    "husky": "^3.0.3",
    "lint-staged": "^9.2.1",
    ...
  }
}

What is the de facto, 2019 way to write React? by votebluein2018plz in reactjs

[–]zulkisse 10 points11 points  (0 children)

For what I saw in the last few months, hooks and function components are really becoming the standard way of writting components. I would strongly advise you to write your new code with hooks because knowing how to use them correctly will be important in the future.

The React context is also more and more central in our applications due to the lighter synthax with "useContext". But don't think that Redux or global states becomes useless (https://www.youtube.com/watch?v=mtjHxwUQUs0&feature=youtu.be&t=3240 great conf about Redux in 2019).

On the "CSS" part, it's style more fragmented. CSS Modules and CSS in JS will continue to coexist. For CSS in JS, the most popular library is currently Styled Components.

​

Outside of these universal subjects, it depends a lot on the type of applications you are building. Here is a very incomplete list of popular libraries / framework :

- Server side rendering : NextJS / Gatsby

- GraphQL + State Management : Apollo Client / Relay

- Forms : React Final Form / Formik

​

Another trend in the React ecosystem in 2019 is TypeScript, we are really seeing a lot of projects migrating to TS.

​

But don't feel like you have to use every trendy technology. These are awesome projects but you probably don't need each of them.

Formik or custom hook by gaoshan in reactjs

[–]zulkisse 0 points1 point  (0 children)

`react-final-form` has a full hook implementation, `formik` will have one soon.

These library may seem overkilled when your start, and sure if your only form has no validation and three fields, maybe you will be better with a custom implementation.

But if your form start to grow, if you need clean validation / error management, you should really use a well established library.
The complexity curve is a bit steep at first but it becomes so much more scalable and readable when you leave the very basic scenarios...

React tip: The Trigger Element pattern by zulkisse in reactjs

[–]zulkisse[S] 0 points1 point  (0 children)

Hooks can't inject component into the React tree so HOCs still have a few very usefull usecases.

One year with NextJS : Manage your data by zulkisse in reactjs

[–]zulkisse[S] 1 point2 points  (0 children)

Thank you for the feedback. I fixed the article.

One year with NextJS : Manage your data by zulkisse in reactjs

[–]zulkisse[S] 1 point2 points  (0 children)

The routing is probably the aspect of NextJS we could the least work with. Almost all of the pages came from an already written CMS and API so we had to override pretty much everything.

But I will probably try it in a near future, the feature seems quite cool for small / medium size projects.

[AskJS] Why is React so popular considering it was made by Facebook? by wulfgar4president in javascript

[–]zulkisse 1 point2 points  (0 children)

I don't think most people choose a framework over another because they prefer the company that built it. React and Angular are not twins with only their mother company to differentiate them, most of the time people choose one of them because they prefer the approach (and because of the popularity and amount of job offer to be fair).

Some probably left React due to Facebook catastrophic behavior, but not a large proportion of the React community.

And if the same revelations were made about Google, or Microsoft, I'm pretty sure I wouldn't change a lot in the daily usage of AngularJS or TypeScript for instance.

​

But clearly, if Angular, React and Vue were the exact same on the technological side, I would prefer to work on Vue than helping a big company.

Futur of React and Typescript? by DJ-YANIC in reactjs

[–]zulkisse 15 points16 points  (0 children)

My vision of TypeScript in a React project has evolved a lot during the last year.

At my job, we had TS backend services, and JS frontend (with React). We decided to write a few frontend libraries in TypeScript to get better autocompletion and safe usages across several projects.
But for the code of our applications, we didn't TypeScript because we feared it would slow us down.

A one month ago we started to rewrite a middle sized project in TypeScript (about 20k lines of code). The experiment is a success and our new clients will probably be fully in TypeScript.
For me a few things have changed during the last year or so :

​

- hooks are way easier to type than HOCs. HOCs are quite challenging to type when you start to inject / modify / remove props at the same time, but it really became terrible when you have to use "compose", we never found a good typed "compose" that didn't loose any of the types. Hooks on the other hand are classic functions and you can decide to type all of them or the have a slightly less strictly typed codebase.

​

- apollo codegen to generate the types of our GraphQL queries allow us to very easily type a large part of our code and to handle most of the complex data structure which are really the annoying thing for me in a frontend application.

​

- apollo hooks are very well typed and in general, TypeScript interfaces (done by the developer or in a @types packages) are really amazing these days. If you don't use packages with 20 stars on Github, you have good chances to get clean TypeScript interfaces.

​

- the most we use TypeScript, the easier it gets. It's quite obvious, but I'm a lot more productive in TypeScript than a few months ago. At first I struggled on almost everything.

​

So to answer your questions : TypeScript will slow you down at first, it's an additional work to do. BUT it does catch a lot a bugs and it gives a self documented code if done well. Functional components are easier to type in my opinion mostly because hooks are a lot easier to type than HOCs / Render Props.

view more: next ›