/7-architectural-attributes-of-a-reliable-react-component/ about dmitripavlutin.com-comments HOT 43 OPEN

Comment written by Adam on 09/26/2017 14:17:04

One aspect that's been puzzling me lately is reusability but being React version agnostic.

For example, if I spend 6 months and write a bunch of standalone components in React 14, FB then release React 15, and I begin to create my base application in React 15. All of those React 14 components are no longer usable in my newer application because they're incompatible. I thus lose all ability to gradually replace components in my application making upgrading versions an expensive process.

I think it would be a whole lot nicer if React had a much smaller footprint, such as Preact, because then components and groups of components could be bundled with their own tiny runtimes, and thus be reusable across React versions. You could even go a step further and say that components written in React should also be usable in Angular, Vue, etc... by way of using custom elements and props. Although that does come with its own difficulties in that passing non-string values becomes a concern for the application using those components.

I remember the days of Gulp when there was a tool you wanted to use, but you needed to either create a wrapper, or wait for one to be created, before you could use it. To me it seems as though we're making all of the same mistakes again with React (Vue, Angular, etc...), because once React departs, we'll be left with a mass graveyard of React modules.

from dmitripavlutin.com-comments.

Comment written by Adam on 09/26/2017 15:53:23

One aspect that's been puzzling me lately is reusability but being React version agnostic.

For example, if I spend 6 months and write a bunch of standalone components in React 14, FB then release React 15, and I begin to create my base application in React 15. All of those React 14 components are no longer usable in my newer application because they're incompatible. I thus lose all ability to gradually replace components in my application making upgrading versions an expensive process.

I think it would be a whole lot nicer if React had a much smaller footprint, such as Preact, because then components and groups of components could be bundled with their own tiny runtimes, and thus be reusable across React versions. You could even go a step further and say that components written in React should also be usable in Angular, Vue, etc... by way of using custom elements and props. Although that does come with its own difficulties in that passing non-string values becomes a concern for the application using those components.

I remember the days of Gulp when there was a tool you wanted to use, but you needed to either create a wrapper, or wait for one to be created, before you could use it. To me it seems as though we're making all of the same mistakes again with React (Vue, Angular, etc...), because once React departs, we'll be left with a mass graveyard of React modules.

from dmitripavlutin.com-comments.

Comment written by velopert on 09/27/2017 04:40:11

Thanks.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 09/27/2017 08:10:55

You're welcome!

from dmitripavlutin.com-comments.

Comment written by Ian Rose on 09/28/2017 20:11:10

Great article! It really got me thinking.

One error though in the impure function example sayOnce. It will first return null then on the subsequent call return 'Hello World!'.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 09/29/2017 03:34:20

Thanks Ian.
The example fixed.

from dmitripavlutin.com-comments.

Comment written by Dawid Karabin on 09/29/2017 23:19:27

You missed (Header); at the end of the example about defaultProps from recompose :)
Good read. A lot of valuable content, thank you!

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 09/30/2017 05:21:15

Nice catch @hinok:disqus. Code updated.
You're welcome!

from dmitripavlutin.com-comments.

Comment written by Rob Brennan on 09/30/2017 20:31:25

What a great post! Nicely done.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/01/2017 04:04:47

Thanks @TheRobBrennan:disqus.

from dmitripavlutin.com-comments.

Comment written by gabrielpoca on 10/02/2017 14:27:25

Thank you Dmitri, this is a very thorough blog post!

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/02/2017 15:57:18

You're welcome @gabrielpoca:disqus! "The devil is in the details"

from dmitripavlutin.com-comments.

Comment written by gabrielpoca on 10/05/2017 10:12:50

There's one thing I was going to mention but forgot. In one place you say that duplication is bad `Since code duplication is a bad practice, how to make components reuse common code?`. I don't think this statement is always true. I've dealt with so many situations where people introduce an abstraction too soon to remove duplication, and when they find out more about the product the abstraction doesn't work out and ends up a mess. I know these is just a detail a blog post that's well written, I'm just pointing out because it may give more people the impression that you must always remove duplication.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/05/2017 10:41:29

Sure, sometimes making small abstractions doesn't give much benefits. But in most of the situations applying DRY principle makes the code better.

As you mention: "when they find out more about the product the abstraction doesn't work out and ends up a mess". I see the problem in the way system changes according to unexpected new requirements. If the system is tightly coupled, you cannot change an existing abstraction implementation with an alternative: thus it's an architecture problem rather than code duplication.

from dmitripavlutin.com-comments.

Comment written by Selwyn on 10/05/2017 21:01:47

Hi, great article!

Regarding 5.1: purification from global variables, I'm wondering what the usage looks like. In the solution example the default export is `defaultProps`. Does that mean using the Header component would be the following?
```
import { defaultProps } from './header.js';
<defaultprops>Some content</defaultprops>
```

Naming seems a bit akward if the above is true...

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/06/2017 03:28:09

Use the default import of a module:

import Header from './header';

<Header>Some header content</Header>

from dmitripavlutin.com-comments.

Comment written by Andrejs Abrickis on 10/06/2017 06:41:23

Thanks, @rainsoft:disqus for providing the essence of Clean Architecture for Web components. Either it's vanilla JS or React or any other frameworks components these are the practices you can apply everywhere. I got some ides how to improve my Vue.js components and can't wait to share this with my team mates.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/06/2017 13:43:51

Definitely these concepts are universal! I'm glad you find the article helpful.

from dmitripavlutin.com-comments.

Comment written by Leon on 10/09/2017 15:18:56

At this point:

```
export function WeatherFetch({ temperature, windSpeed }) {
return (
<weatherinfo temperature="{temperature}" windspeed="{windSpeed}"/>
);
}
```

Why does the WeatherFetch function need to exist?

from dmitripavlutin.com-comments.

Comment written by Jack McCloy on 10/09/2017 22:30:00

Really great article, good work!

I particularly appreciate the distinction you drew between "testable" components and "tested" ones. I think the same can apply to reusable components vs. reused ones, where all (or at least most) components should be built to be reusable regardless of whether they currently have a reuse case.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/10/2017 08:09:52

WeatherFetch is needed because it holds the logic of handling the fetch. For instance you could show a loading message while the request is in progress, or show an error message on a failed request.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/10/2017 08:11:17

Thanks @jackmccloy:disqus.
Writing reusable components as a criteria of correct design is a good approach too.

from dmitripavlutin.com-comments.

Comment written by Leon on 10/10/2017 08:27:09

But WeatherFetch doesn't hold that logic, the HOC created by the "lifecycle" function holds that logic. The component tree as of section 5.3 would be:

<connect(lifecycle(weatherfetch))> -> <lifecycle(weatherfetch)> -> <weatherfetch> -> <weatherinfo>

So <connect(lifecycle(weatherfetch))> holds the logic of interacting with the redux store and mapping the state to its child component's props. <lifecycle(weatherfetch)> holds the logic of calling the fetch function, and <weatherfetch> does... nothing? Just renders WeatherInfo, it doesn't change the props or anything, it could basically be replaced with "(props) => <weatherinfo {...props="" }=""/>" no? Which is basically pointless surely?

from dmitripavlutin.com-comments.

Comment written by Leon on 10/10/2017 08:33:38

Also sorry for the weird formatting. I think Disqus is trying to format my react excerpts as if they're HTML. This is what I'm getting at:

https://gist.github.com/leo...

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/10/2017 08:37:30

`lifecycle` only triggers the fetch and extracts the side effect from component. That's all.

If you extend later the WeatherFetch functionality, you would see that it can show a loading message for example (which is handling the fetch logic):

export function WeatherFetch({ temperature, windSpeed }) {
  if (!temperature || !windSpeed) {
    return <div>Loading...</div>;
  }
  return (
    <WeatherInfo temperature="{temperature}" 
          windspeed="{windSpeed}"/>
   );
}

Of course, if you don't need to handle the request processing, you could simply omit WeatherFetch and apply lifecycle directly to WeatherInfo (but that's not the point of the example and chapter, so I omitted it).

from dmitripavlutin.com-comments.

Comment written by Leon on 10/10/2017 08:44:50

Okay so in that example I can see that it now has reason for existing, but in the example above (section 5.3), it has no reason for existing.

from dmitripavlutin.com-comments.

Comment written by Yongsun Lee on 10/14/2017 19:28:41

Awesome post! Thanks Dmitri.

from dmitripavlutin.com-comments.

Comment written by Łukasz Ostrowski on 10/19/2017 17:34:59

good job. also pretty nice and uncommon patterns you used

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/20/2017 03:43:42

Thanks @disqus_wdOhBqNNFf:disqus. Trying to get some fresh air. :)

from dmitripavlutin.com-comments.

Comment written by goodmind86 on 11/23/2017 14:20:05

Sounds like SOLID principles

from dmitripavlutin.com-comments.

Comment written by Maxwell vp on 01/10/2018 13:07:47

The If component can be improved even more:

function If({ component: Component, condition }) {
return condition && <component/>;
}

or using arrow functions:

const If = ({ component: Component, condition }) => condition && <component/>;

from dmitripavlutin.com-comments.

Comment written by Spamall on 09/15/2018 23:57:25

Yeah. Sounds like SOLID applied to React.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 07/05/2019 16:58:12

That's a good idea!

from dmitripavlutin.com-comments.

Comment written by Alex Golovan on 04/26/2020 07:12:37

Best article so far - thanks, Dmitri!

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 04/27/2020 07:54:11

You're welcome!

from dmitripavlutin.com-comments.

Comment written by Angelescu Violeta on 10/08/2020 11:22:33

good articles !

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 10/08/2020 12:33:55

Thank you Violeta.

from dmitripavlutin.com-comments.

Dmitri Pavlutin, thank you!

from dmitripavlutin.com-comments.

Dmitri Pavlutin, thank you!

You're welcome @polyakh!

from dmitripavlutin.com-comments.

This is a really well written article, I guess I will have to come back here many times to properly absorb the contents as I practice them, also is there a link to a repo where you have really utilised some of these in an application, will really love to take a dive into it.

from dmitripavlutin.com-comments.

Well constructed principles and examples. One suggestion: In the beginning of section 7 I think you may mean that it's hard to "overstate" the importance of readable code. It's very easy to "underestimate" the importance, and people do that all the time.

from dmitripavlutin.com-comments.

This is a really well written article, I guess I will have to come back here many times to properly absorb the contents as I practice them, also is there a link to a repo where you have really utilised some of these in an application, will really love to take a dive into it.

Thanks @NateOs! Unfortunately, I don't have an open sourced application I could show. But I might think about creating a boilerplate React application.

from dmitripavlutin.com-comments.

Well constructed principles and examples. One suggestion: In the beginning of section 7 I think you may mean that it's hard to "overstate" the importance of readable code. It's very easy to "underestimate" the importance, and people do that all the time.

Thanks @escornwell! I've updated the post with your suggestion regarding "overstate".

from dmitripavlutin.com-comments.