# Chapitre 1 : Philosophie React
## Composants vs Templates
### L'approche PHP traditionnelle
En PHP, vous séparez généralement :
- **Le contrôleur** : logique métier
- **La vue** : template HTML avec des variables
```php
// Contrôleur
$users = $userRepository->findAll();
include 'views/users.php';
// Vue (users.php)
= htmlspecialchars($user->name) ?>
```
### L'approche React
En React, **logique et rendu sont ensemble** dans un composant :
```javascript
function UserList({ users }) {
// Logique ici si nécessaire
const activeUsers = users.filter(u => u.active);
// Rendu
return (
{activeUsers.map(user => (
{user.name}
))}
);
}
```
**Pourquoi ?** Parce que la logique d'affichage et le rendu sont intrinsèquement liés. Les séparer artificiellement complique la maintenance.
## Le Virtual DOM
### Le problème avec le DOM réel
Manipuler le DOM est lent. Chaque modification peut déclencher un recalcul du layout et un repaint du navigateur.
```javascript
// Approche classique - chaque ligne touche le DOM
document.getElementById('name').textContent = user.name;
document.getElementById('email').textContent = user.email;
document.getElementById('role').textContent = user.role;
```
### La solution React
React maintient une copie légère du DOM en mémoire (Virtual DOM). Quand les données changent :
1. React crée un nouveau Virtual DOM
2. Compare avec l'ancien (algorithme de "diffing")
3. Calcule les changements minimaux
4. Applique uniquement ces changements au vrai DOM
```javascript
// Vous décrivez juste le résultat souhaité
function UserCard({ user }) {
return (
{user.name}{user.email}{user.role}
);
}
// React s'occupe d'optimiser les mises à jour
```
## Flux de données unidirectionnel
### Le problème du two-way binding
Dans certains frameworks, les données circulent dans les deux sens : la vue peut modifier le modèle et vice versa. Cela peut créer des boucles et rendre le debugging difficile.
### La solution React
En React, les données descendent toujours du parent vers l'enfant via les **props** :
```
App
│
▼ props (users)
UserList
│
▼ props (user)
UserCard
```
Si un enfant veut modifier des données, il appelle une **fonction** passée par le parent :
```javascript
function App() {
const [users, setUsers] = useState([]);
const deleteUser = (id) => {
setUsers(users.filter(u => u.id !== id));
};
return ;
}
function UserList({ users, onDelete }) {
return (
{users.map(user => (
))}
);
}
function UserCard({ user, onDelete }) {
return (
{user.name}
);
}
```
Les données descendent (props), les actions remontent (callbacks).
## Déclaratif vs Impératif
### Approche impérative (jQuery)
Vous décrivez **comment** faire les choses, étape par étape :
```javascript
// "Quand le bouton est cliqué, trouve l'élément, modifie son contenu..."
$('#btn').click(function() {
const count = parseInt($('#count').text()) + 1;
$('#count').text(count);
if (count > 10) {
$('#count').addClass('warning');
}
});
```
### Approche déclarative (React)
Vous décrivez **ce que** vous voulez en fonction de l'état :
```javascript
function Counter() {
const [count, setCount] = useState(0);
return (
10 ? 'warning' : ''}>
{count}
);
}
```
Vous ne dites pas "ajoute la classe warning". Vous dites "si count > 10, la classe est warning". React se charge du reste.
## Comparaison avec d'autres approches
^ Concept ^ PHP/jQuery ^ React ^
| Où est la logique ? | Séparée (MVC) | Dans le composant |
| Comment modifier l'UI ? | Manipuler le DOM | Changer l'état |
| Flux de données | Bidirectionnel possible | Unidirectionnel |
| Paradigme | Impératif | Déclaratif |
## Points clés à retenir
1. **Composants** : blocs réutilisables qui encapsulent logique et rendu
2. **Virtual DOM** : React optimise les mises à jour automatiquement
3. **Flux unidirectionnel** : données vers le bas, actions vers le haut
4. **Déclaratif** : décrivez le résultat, pas les étapes
[[:15_training:module2-introduction-react:start|← Retour au module]] | [[:15_training:module2-introduction-react:jsx|Chapitre suivant : JSX →]]