Heures d'ouverture

9h-12 & 14h-18h du Lundi au Vendredi

Appelez-nous

+33 1 83 64 25 33

Nous sommes à votre disposition





Les Basses Forges, 35530 Noyal-Sur-Vilaine

Pourquoi nous ne développons pas avec React Native ?

Beaucoup de gens évaluent actuellement « React Native » comme une plateforme pour développer leur prochaine application mobile. Ce n’est pas une question triviale. La commutation de votre plateforme de développement logiciel implique un coût d’installation élevé et aura un impact profond sur votre flux de travail de programmation quotidien. C’est aussi l’une des décisions les plus coûteuses à inverser après que quelque chose de substantiel a été construit.

Peut-être plus important encore, vos plateformes de développement logicielles vous façonnent également en tant qu’ingénieur logiciel. Une plateforme de développement logiciel encourage (ou force) l’utilisation d’une langue par rapport à une autre, hiérarchise certaines architectures par rapport à d’autres, nécessite l’utilisation d’outils et de workflows spécifiques et vous associe à tout un écosystème et sa communauté de développeurs.

Facebook veut que vous changiez :

Les efforts soutenus et laborieux de l’équipe React Native correspondent à l’ambition. Ils ont produit une plateforme de développement logiciel si importante qu’elle peut légitimement être considérée comme un remplacement de notre pile traditionnelle Xcode / Swift / ObjC.

Serait-ce un remplacement viable? Les articles de blog que nous avons lu à propos de React Native fournissent une évaluation plutôt sommaire. Personne n’a évalué ses avantages et ses inconvénients avec la profondeur que vous attendez de quelqu’un qui essaie de vous persuader de changer votre plateforme de développement logiciel.

Après avoir passé plusieurs mois à utiliser React Native, nous avons découvert que ce n’est ni une plateforme que nous développerions, ni une plateforme dont nous recommanderions l’utilisation.

Cet article propose de fournir une évaluation plus approfondie des avantages et des inconvénients de passer du développement Swift à React Native, et plaidera contre le changement.

Le style déclaratif

Une chose que nous avons trouvé agréable en travaillant avec React Native est le style déclaratif dans lequel l’interface utilisateur est programmée. Dans la façon de faire les choses, l’interface utilisateur est une fonction de l’état et des propriétés, alors que dans Cocoa Touch, l’interface utilisateur est impérativement écrite.

L’exemple suivant clarifiera ce que nous avançons. Supposons que notre interface utilisateur doit inclure un petit carré en haut à gauche de l’écran, ce petit carré devrait être rouge si, disons, l’utilisateur est connecté et vert si l’utilisateur n’est pas connecté.

Voici comment nous le faisons généralement sur iOS :

 

class ViewController: UIViewController {

let indicatorView = ConnectivityIndicatorView()

override func viewDidLoad() {

super.viewDidLoad()

let indicatorViewFrame = CGRect(origin: CGPoint.zero, size: CGSize(width: 20, height: 20))

indicatorView.frame = indicatorViewFrame

view.addSubview(indicatorView)

}

}

class ConnectivityIndicatorView: UIView {

var isConnected: Bool = false {

didSet {

if isConnected {

backgroundColor = .green

} else {

backgroundColor = .red

}

}

}

override func didMoveToSuperview() {

super.didMoveToSuperview()

let weAreConnected: Bool = arc4random()%10 > 4

self.isConnected = weAreConnected

}

}

 

Dans le style impératif, vous spécifiez toutes les étapes requises pour mettre à jour l’interface utilisateur. Nous devons écouter les changements dans isConnected et mettre à jour la vue en conséquence. Nous disons à iOS comment calculer l’état.

Comparez cela avec la manière déclarative de React Native :

Exprimez simplement la façon dont votre application doit être consultée à un moment donné, et React Native gérera automatiquement toutes les mises à jour de l’interface utilisateur lorsque vos données sous-jacentes changeront.

class Root extends Component {

render() {

return (

<ConnectivityIndicatorView />

);

}

}

class ConnectivityIndicatorView extends Component {

constructor() {

super()

this.state = {

isConnected: false

}

}

componentDidMount() {

var weAreConnected = Math.floor(Math.random() * 10) > 5;

this.setState({ isConnected: weAreConnected });

}

render() {

var color = this.state.isConnected ? ‘green’ : ‘red’;

return (

<View style={{‘backgroundColor’: color, ‘width’: 20, ‘height’: 20}}>

</View>

)

}

}

 

Le style déclaratif de React Native vous permet de décrire votre interface utilisateur dans la méthode render () de la vue. Le cadre React Native garantit que tout changement d’état déclenche le rendu. Les changements dans vos données (c’est-à-dire lorsque les changements de backgroundColor) déclenchent automatiquement un changement dans l’interface utilisateur.

Cela supprime la mise à jour manuelle des vues en réponse aux modifications du modèle. Que vous aimiez ou non être déchargé de cette responsabilité, React Native fait un très bon travail pour s’assurer que les mises à jour sont effectuées selon vos descriptions, et vous n’avez plus à vous soucier de déployer ni de maintenir un accesseur de propriétés pour cette variable isConnected.

Vous remarquerez également que vous finissez par raisonner les éléments de l’interface utilisateur comme s’il s’agissait de fonctions plutôt que d’instances de classes. Ils prennent en état et rendent un objet UIKit. Le but d’un composant est de retourner lui-même dans l’état qu’il est censé être, lorsque demandé.

Nous avons trouvé que c’était un moyen utile de penser à l’interface utilisateur. C’est une bonne évolution de la part de MVC, le View n’étant responsable que de l’affichage et non de la gestion des données.

Itérations plus rapides

Lorsque vous programmez dans React Native, le framework crée un serveur local qui sert les fichiers JavaScript sur lesquels vous travaillez. Vous créez l’application une seule fois, l’exécutez sur le simulateur iOS ou sur un périphérique et React Native s’assure que toutes les modifications que vous apportez au JavaScript sont reflétées dans l’application.

Vous avez deux options :

Live Reloading rechargera l’application chaque fois que vous éditez et enregistrez un de ses fichiers. Principalement, cela vous évite de passer au simulateur et d’appuyer sur ⌘ + R.

Hot Reloading ne recharge pas toute l’application, il ne recharge que le fichier que vous venez d’éditer. Si, par exemple, vous travaillez sur l’interface utilisateur d’une cellule de vue de la table au fond d’une pile de navigation, le changement sera immédiatement reflété dans la cellule que vous voyez dans le simulateur, vous n’aurez pas à naviguer de l’écran de démarrage aux cellules pour voir les changements et le composant restera dans l’état où il est déjà. C’est une expérience de programmation WYSIWYG, un luxe que Xcode ne vous a jamais offert pour vos applications.

Nous nous souvenons avoir dû ajouter une méthode de débogage dans AppDelegate pour chaque ViewController que nous voulions que l’application affiche au démarrage, de sorte que je nous n’aurions pas à naviguer manuellement à chaque fois que nous utilisons l’application pour voir les changements juste codé. Hot Reload nous donne l’impression d’être des hommes des cavernes.

La boucle React de rétroaction de Native est extrêmement faible. Il faut moins d’une ou deux secondes entre l’enregistrement d’un fichier et la modification de votre application. C’est dix fois moins que le cycle typique de Build and Run auquel nous sommes habitués dans Xcode.

Cross-plateforme

Cela vous rappelle quelque chose ?

« Super application! Est-ce qu’il fonctionne sur Android? […] Oh. Et quand prévoyez-vous de sortir une version Android? […] Oh. «

Votre base de code peut maintenant créer une application qui peut fonctionner sur des millions d’appareils supplémentaires, afin que vous augmentiez votre portée de plusieurs ordres de grandeur.

Nous pouvons certifier que la même base de code produira de manière fiable l’application de même apparence et de même action sur les deux plates-formes.

Être capable de produire une incarnation Android de votre application à partir de la même base de code, graphiquement et fonctionnellement équivalente à son homologue iOS, est habilitant.

Les avantages évidents de tout framework multiplateforme sont toujours convaincants : développement du marché, base de code unifiée, et un ensemble de compétences unifié requis pour maintenir la base de code de l’application. Cela permet des mises à jour de code over-the-air. Tout changement dans votre code JavaScript peut être instantanément transmis à vos utilisateurs pendant que l’application est en production.

Roadmap incertaine

L’une des principales préoccupations concernant l’utilisation de React Native est le manque d’engagement à long terme pour le projet.

Si ce projet était un simple composant plug-and-play de mon application, comme une bibliothèque de mise en réseau ou un convertisseur SVG vers CGPath, sa survie et sa maintenance à long terme seraient une préoccupation secondaire, car si ses développeurs l’abandonnent, ou si son rythme de développement est insatisfaisant – aussi triste que cela puisse être -, je peux le remplacer par une bibliothèque à peu près équivalente ou en assumer moi-même la maintenance. Ce pourrait être un gros problème, mais ce ne serait pas critique. Je m’assure d’avoir suffisamment de couplages avec toutes mes bibliothèques tierces / CocoaPods pour que tout le projet ne s’effondre pas si une bibliothèque stagne ou disparaît.

Mais React Native n’est pas un CocoaPod plug-and-play, ce n’est pas un simple SDK, ce n’est pas une simple bibliothèque, c’est une plateforme de développement de logiciels complète. Dire que mon application a un « couplage étroit » serait un euphémisme, mon application en dépend entièrement. Si Facebook cesse de maintenir React Native, mon application stagnera et il n’y aura plus d’alternative à ma disposition. Si je veux continuer à le maintenir moi-même, je devrais me familiariser avec la source React Native, ainsi qu’avec la base de code React.js, les outils CLI React Native et JavaScriptCore. La communauté veillera-t-elle à ce que le projet survive ? Peut-être, mais si c’est le cas, ce ne sera probablement pas au rythme auquel nous sommes habitués.

Sur le référentiel GitHub, vous verrez une nouvelle version de React Native à peu près une fois toutes les deux semaines. Pas mal pour une plateforme de développement de logiciels qui cible deux plateformes de développement de logiciels distincts et complexes. Aussi prometteur que cela puisse être aujourd’hui, Facebook n’a pris aucun engagement à long terme pour maintenir React Native pendant une période prolongée. La société n’a fourni aucune garantie qu’elle ne tirera pas  un trait sur le projet, mais pour la durée de vie de votre application. En d’autres termes, vous n’avez actuellement aucune garantie qu’il sera compatible avec iOS 11 ou 12.

« Voici l’année prochaine! »

Met fin à un blog officiel React Native d’avril 2016. Qu’en est-il des suivants? Facebook est inquiétant à ce sujet.

Nous publierons des plans très bientôt – Konstantin

Dit l’équipe React Native, en décembre 2015. Ces plans n’ont pas encore été publiés. Les résultats de l’analyse coût-bénéfice à long terme de Facebook de React Native, si jamais il y en avait un, sont moins impressionnants que vous ne le pensiez.

Encore une fois, nous ne parlons pas d’un Cocoapod individuel, nous parlons de la seule plateforme sur laquelle votre code peut fonctionner. C’est le genre de choses sur lesquelles vous avez besoin d’une visibilité à très long terme, et vous n’en avez pas.

 

Retrouvez la suite de cet article la semaine prochaine dans les actualités de TACTfactory. 

 

Source : https://arielelkin.github.io/articles/why-im-not-a-react-native-developer.html