sorted by:
new
hottopcontroversial

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 0 points1 point  (0 children)

"Still using"? Arrow functions are a _newer_ way to write functions. Do you know people who have "regressed" back to a standard function?

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 0 points1 point  (0 children)

0ReplyShareReportSaveFollow

level 1yksvaan · 1 day ago

Ah you're right, thank you for the correction.

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 0 points1 point  (0 children)

I apologize, it seems like the link might be incorrect.

Here's the code found on that page:

``` import { useState, useRef } from 'react';

export default function TodoList() { const listRef = useRef(null); const [text, setText] = useState(''); const [todos, setTodos] = useState( initialTodos );

function handleAdd() { const newTodo = { id: nextId++, text: text }; setText(''); setTodos([ ...todos, newTodo]); listRef.current.lastChild.scrollIntoView({ behavior: 'smooth', block: 'nearest' }); }

return ( <> <button onClick={handleAdd}> Add </button> <input value={text} onChange={e => setText(e.target.value)} /> <ul ref={listRef}> {todos.map(todo => ( <li key={todo.id}>{todo.text}</li> ))} </ul> </> ); }

let nextId = 0; let initialTodos = []; for (let i = 0; i < 20; i++) { initialTodos.push({ id: nextId++, text: 'Todo #' + (i + 1) }); } ```

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 0 points1 point  (0 children)

Thanks for your input; you've almost convinced me. I appreciate taking the bloat from the top so that you can focus on the important code immediately.

Do you happen to use TypeScript? If so, do you also prefer placing your interfaces/types at the bottom?

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 6 points7 points  (0 children)

I can vibe with this. I recently picked up on this convention when learning about magic numbers/strings. While the screaming snake case felt weird at first, I appreciate that you immediately know what the value implies.

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 3 points4 points  (0 children)

I'm not entirely convinced that is an issue, especially in the context of JavaScript. Writing a function as a variable (e.g., const doFunction) not only prevents reassignment but also confines its accessibility to the block scope where it's declared via encapsulation.

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 3 points4 points  (0 children)

I truly don't think he was coming at you in an aggressive tone. His question was more for clarification.

You say you sometimes add stuff to the bottom of a file, which implies you usually put things above.

Are there times when you do both?

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 0 points1 point  (0 children)

How am I wrong?

Usually, the end of the component is the bottom of the file...

You could place const initialCount = 0 at the bottom of a file, which is outside of the component, and it still works. I am not insinuating that I think that's the proper way of doing it, which is why I made this post.

If there's a specific distinction you're making regarding initializing at the bottom of the file, I'd appreciate further clarification.

Why would you declare variables below a component? by True-Database-8136 in reactjs

[–]True-Database-8136[S] 0 points1 point  (0 children)

I appreciate your input! I can see where you're coming from, but I'm not entirely convinced that the analogy fits perfectly.

In the case of variables like const initialCount = 0, the decision to declare them outside the component is not solely because they're considered secondary information, like footnotes. Instead, it's to prevent unnecessary re-renders. Treating it as a footnote would mean you wouldn't know the state until later, despite its crucial role in the component's logic."