Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in
H
Hello Gargan
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • arturo
  • Hello Gargan
  • Wiki
  • 6—Component Cookbook

6—Component Cookbook

Last edited by arturo Jun 29, 2021
Page history

There is a lot of existing simple rules to follow while creating a Component Tree for a frontend application, such as: avoid "prop drilling" ; or what we said earlier "the deeper, the dumber". This cookbook presents some design patterns reusable for PureScript Reactix components.


  • add PureScript examples

Base components

  • deepest node of the component tree
  • only contain HTML element without any logic
  • variadic arity regarding props specs

      Reactix.DOM.HTML examples


Container components

  • wrapping an existing component
  • communicate with the store or other data-relation library (eg. Relay)
  • dispatch behaviours and data
  • better suffixed as <component-container>
  • smart and dumb components article to illustrate some examples

Deep dependency injection

  • sharing data that can be considered as global, or reusable semi-local logic, for the component tree
  • use the context API in ReactJS

Heads up: predictable state containers are often relying on this pattern. This is the choice we have chosen for the project too

      context example


Dual binding

  • offer a two-way binding on a form input element or a component
  • non native in ReactJS (contrary to VueJS v-model for example)
  • add dualbinding with "FormValidation" hook for inputs
  • idem, via Toestand (maybe check how Formula library is written)

Instance reference

  • use ref in ReactJS
  • allow parent component to perform DOM manipulation


Layout component

  • a type of component used once per page
  • naming format adopting the <the-component> prefix
  • it is ok if they contain some "container component" logic (eg. communicating with the stores)

Heads up: the project contains some "/layouts/**.purs" files. To be clear here, these components (in addition to the "/pages/**.purs" ones) tick all the boxes concerning layout component patterns. Two differences:

  • prefix has been altered for a more contextualised value
  • they are subject to framework automations

  example


Composition component

  • surcharge a component with another given one
  • previous major React API also provide "mixins", today deprecated for obvious reasons, now "hooks API" is the main word

      hook example


Placeholder component

  • clone of an existing component displayed while on pending process for example
  • template created from a generator

      blank placeholder with cloak example


Transcluded component

  • via transmission of reactjs rendered elements as props
  • or in a more fashion way (following the likes of VueJS slots) via transmission of array of elements

  slots example


« 5 — Form validation             7 — Miscellaneous »
Clone repository
  • 1—Application structure
  • 2—Components
    • 2.1—Component structure
    • 2.2—Page and Layout structure
    • 2.3—Store structure
  • 3—SASS-usage
    • 3.1—SASS files
    • 3.2—CSS integration model
  • 4—UI library
  • 5—Form validation
  • 6—Component Cookbook
  • 7—Miscellaneous
  • 8—Milestones
  • Home
More Pages

New Wiki Page

Tip: You can specify the full path for the new file. We will automatically create any missing directories.