2

I am new to React and I've come across two bits of code that I think do the same thing, but I am not entirely sure.

    import React from 'react'
    
    export default function TestComponent() {
        return (
            <div>
                
            </div>
        )
    }

as well as

    import React from 'react'

    function TestComponent() {
        return (
            <div>
                
            </div>
        )
    }
    
    export default TestComponent

The only difference that I can see between the two is that the export is just put at the end in one of them but they should both behave the same if my understanding is correct. Does this have any real effect on the behaviour of the code?

machineghost
  • 33,529
  • 30
  • 159
  • 234
Rae Green
  • 21
  • 2
  • 3
    Both are exactly same...This is known as `default export`. When importing you can name anything like `import TestC from "./TestComponent";` You can only export default only one time per module. – DecPK May 22 '21 at 02:11
  • 1
    They are same... – Zhang TianYu May 22 '21 at 02:11
  • Just like a lot of things in life...there are different ways to skin a cat and end up with same result – charlietfl May 22 '21 at 02:12
  • It's crazy how much use react is getting with its boilerplate - was this created with `create-react-app`? – Cole Henrich May 22 '21 at 02:17
  • [They are not the same](https://stackoverflow.com/a/58441210/1048572) if you reassign `TestComponent` inside the module. Which nobody does, so it doesn't matter… – Bergi May 22 '21 at 02:19

5 Answers5

1

All in all, that's not a matter for React or components, but for coding in general and JavaScript modules especially.

It might be matter of scalability on the dev side, i.e. how you yourself will be able to manage your code if it grows. If you have to add and maintain more functions / classes / variables, it's a benefit to separate the place in code where you define the functions / classes / variables from that where you define wich to export and from that where you define your default export because you can only have one default export, but many non-default exports - imagine you decided to re-declare which export is the default one, labeling the new one as "default" and forget to "de-label" the old one, then with defining "default" somewhere in your code the old default might outrule the new one because being later in the code. Declaring exports at the end of file will give you helpful overview.

As question of personal style might be if you want to use "export" directly where a function / class / variable is defined to see immediately what functions / classes / variables are "public" and which are "private" (i.e. not exported).

If your code grows into something requiring some kind of an API, you might use the option to export as, e.g. maintaining complicated "speaking" functions names inside of your code, but exposing the functionality by "simple" names to the component's consumers. This would be obviously easier if being separated from the definitions of the functions itself.

In general, for your own sake, be as explicit as possible, here: separate "export" instructions. Trying to have short and clever code leads to more complexity than myriads of "stupid simple" code. React and other soft- and hardware is not impressed how cleverly you may have code golfed, very rarely something would be faster or slower, since optimization should not be part of developing, and trying to generalize should be well dosed.

For JavaScript "ES6" modules used by React for components, the 2015 introduction https://hacks.mozilla.org/2015/08/es6-in-depth-modules/ is still the best reference and surely a must-read.

hh skladby
  • 101
  • 6
  • "*the old default might outrule the new one because being later in the code.*" - no, it just throws an exception if you try to export multiple bindings under the same name. – Bergi May 22 '21 at 12:47
0

As several in the comments have already said, those two code blocks are practically equivalent (ie. they are the same). In theory you could add code to make them different (eg. you could re-assign the function before exporting it in the second example) ... but it would be pretty contrived.

Does this have any real effect on the behaviour of the code?

No. What matters is just that you name your exported functions at all (and in fact the Create React App rules will fail if you don't, because it could make your debugging harder).

machineghost
  • 33,529
  • 30
  • 159
  • 234
0

Both code blocks are functionally the same but I personally favor the second.

Both use a function declaration but the second one permits you to swap the declaration out for a function expression or class declaration without modifying the export.

Also, in cases where you can have multiple exports from a single file, it's a useful convention to declare the default export at the bottom of the file.

Andrew Gillis
  • 3,250
  • 2
  • 13
  • 15
  • Why would you want to swap out a declaration for a function expression? And if you do, you have to change the statement anyway… – Bergi May 22 '21 at 02:33
  • "*in cases where you can have multiple exports from a single file*" - the better convention is to name your exports in that case :-) – Bergi May 22 '21 at 02:34
  • Well I mostly use function expressions because the syntax in TypeScript is more friendly, the export would remain the same. To me it is more logical that the export in all cases basically says "export variable x from this file". You are right that named exports are better in most cases but if you are developing components for reuse it is sometimes helpful to allow it to be imported by any name. And I am aware that you can import things under any name but it's about syntax and developer taste. – Andrew Gillis May 22 '21 at 02:56
0

It's the same thing in your case because you are creating your React component by using a 'classic' Javascript function.

I personnally use the first code to save a line but the second code is usefull when you have a React.js component written in arrow function like as is :

const yourComponent = () => {};

export default yourComponent;

In this case, you must use this line at the end of your file :)

0

Both are technically same, the only difference is that you add an extra line to export your functional component in second code. I generally prefer second code because it keeps my code clean when compared to first code.

Kishore S
  • 1,831
  • 2
  • 8
  • 15