Skip to content

Latest commit

 

History

History
87 lines (62 loc) · 4.03 KB

INTRO.md

File metadata and controls

87 lines (62 loc) · 4.03 KB
Raw

A very brief introduction to Fulcro

Workshop agenda

  1. Intro (here)
  2. Workshop exercises (1-9)
  3. Q&A session
  4. (Coding exercises - likely a home work, unless we are really quick)
    • Learn building a Fulcro app from "scratch," one concept at a time

Fulcro intro

(See a recording of me giving this introduction)

Disclaimer: I'm not going to talk much about WHY things are they way they are. Read https://fulcro-community.github.io/guides/tutorial-minimalist-fulcro/index.html#_why_fulcro to learn about that.

Why Fulcro?

Because it provides a complete, integrated model and solution for building non-trivial business applications, applications that span front- and backend as they essentially all do. Being integrated, it substantially reduces the amount of boilerplate you have to write, and being "complete," it often provides all you need, without having to add other libraries or make ad-hoc solutions.

  • (Really) Data-driven, UI = f(data)
  • Sustainable webapp development - minimize incidental complexity
  • Dev friendliness - co-location, tooling, navigability => no more editing N disparate places, searching for string IDs!
  • Extreme customizability
  • Graph API >> REST (see Wilker's talk)

What is Fulcro?

Fulcro is a full-stack web framework for a graph API. Let's unpack that:

  • Full-stack = both frontend and backend
  • On the frontend we have a UI tree composed of React components
  • It talks to a graph API on the backend to query for data and to effect mutations (changes)
    • A single endpoint (x REST)
    • Frontend describes what data it wants using EDN Query Language (EQL) and backend fills them in, returning a data tree
  • On the backend we have Pathom - Fulcro's twin library (cljc) that parses EQL and answers with data
    • You code resolvers that provide parts of the answer
    • Your Pathom resolvers typically talk to a DB such as Datomic and PostgreSQL or remote REST APIs
    • Note: Pathom can also run in the browser and it can work as an adapter of a REST API, as demonstrated on the Twitter v1 API in Wilker Lucio's talk "Data Navigation with Pathom 3"

Let's zoom in on the Frontend. It has:

  • the UI component tree
  • a client-side state, called client DB, and storing data mostly in a normalized form
  • an asynchronous transaction subsystem (Tx) for triggering local and remote mutations and data loads from the components

Let's zoom in even more, on the UI tree and its rendering:

  1. Fulcro asks the Root component for its query, which composes the queries of its children (and so forth)
  2. Fulcro fulfills the query using the data in the client DB, producing a tree of data, also known as props (= properties)
  3. Fulcro invokes the Root's render function passing it the props tree; Root in turn renders its children, passing them the relevant sub-trees

Fulcro component

What is a Fulcro component anyway?

(defsc <Name> [this props]
  {<config options>} ; :query, :ident, ...
  (dom/div 
    (dom/h1 "Hello" (:name props) "!")
    (some-child-component (:some-child props))))

Keyword cloud

  • Component
  • Component tree
  • Data tree
  • Mutation
  • Transaction
  • Client DB
  • EQL
  • Query

TP: You do not need to understand everything here. We will be coming back to these terms in the exercises. There you will experience and grok them.

Additional resources

  • Data Navigation with Pathom 3 by Wilker Lucio is a great explanation of the problem with REST and multiple clients (e.g. UI components) with varying data needs and why an attribute-centric approach - such as implemented by Pathom - is a better solution. You will see Pathom in action and learn about some of its super-powers. all of this in just 45 minutes.