Likely Correct React Apps

2024-12-04 v0.2

Introduction

  • Idea: We know what is a
    • Likely correct software 1: ✅
    • React software: ✅
  • Proposal
    • Apply the principles of likely correct software
    • To the specifics of React

Formalism, correctness, cost 1

Method Correctness Cost
Formal Provably correct Expensive
Semi formal Likely correct Affordable
Informal Maybe correct Minimal, but it’s a debt

The software development process

Input Process /
Step		 Deliverables
Problem Understanding Model
Model Design Specification
Specification Implementation Code
Code Verification Software

A likely correct software development process 1

  • Likely correct understanding ✅
    • There are good (semi) formal methods
  • Likely correct design ✅
    • There are good (semi) formal methods
  • Likely correct implementation ✅
    • Even provably correct is possible
  • Likely correct verification ✅
    • Even provably correct is possible

A likely correct React app …

  • Uses a likely correct software development process
  • Which produces React-specific deliverables
  • Which are all formal or semi-formal

React – Specific software

  • Solves specific problems
    • Data driven
    • Interactive user interfaces
    • Fragile platform (The browser)
  • Uses specific models
    • Ontology, taxonomy, choreography 1
    • Design systems 2
  • Produces specific code
    • Components, state, CSS
  • It turns out React specifics are also React pain points
  • It might be a coincidence, but doesn’t really matter

React – Specific pain points 1

Pain points: Architecture + State

  • Code Architecture – 37%
    • “Organizing and maintaining your codebase.”
    • aka. Structuring components
  • State Management – 32%
    • “Managing global data state in complex applications.”
    • aka. The official React state solution is not enough

Pain point: Presentation (UI/UX) 1

Consistent—coherent and uniform—user interfaces display no visual and logical glitches

  • This comes from the browser, not React
  • This is hard, in my 15 years experience

Official remedies for pain points

  • Code / component architecture
    • SRP (Single responsibility principle) 1
  • State management
    • DRY (Don’t Repeat Yourself) 2
    • Lift state up 3
    • Add inverse data flow 4
    • State machine 5
  • Presentation: Not a single word

The likely-correct approach gives better remedies

Specific software Specific problems Specific solutions /
Deliverables /
Models
Components Code Architecture Ontology, taxonomy
Interactive State Management Choreography
CSS, Browser Consistent UI/UX Design systems

Are these remedies formal / semi-formal?

Specific software Specific problems Specific solutions /
Deliverables /
Models		 Method Formalism
Components Code Architecture Ontology, taxonomy Category theory 1 Formal
Interactive State Management Choreography Finite state machines 2 Formal
CSS, Browser Consistent UI/UX Design systems Component-based UI framework with constraints-based API 3 Semi-formal

The theory looks good

Input Process /
Step		 Deliverables
Problem Understanding Ontology, taxonomy
Choreography
Design systems
Ontology, taxonomy
Choreography
Design systems		 Design Specification
Specification Implementation Code
Code Verification Software

In theory

  • We’ve adapted React
  • To the principles of likely correct software

In practice

  • I’m building a pilot project, an Olog Editor 1
  • Based on the theory above
  • Which, by the way
    • Offers a missing tool / method
    • To create provably correct
    • Ontology and taxonomy

Drawing Hands by M. C. Escher, 1948, Lithograph, Wikipedia

What’s next?

  • Diagrams are code 1
  • “This is what the endgame should be”

Thank you!

https://osequi.com