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
  • 4—UI library

4—UI library

Last edited by arturo Nov 29, 2021
Page history

At this moment in PureScript, only few examples of existing component library exist. We can think of "purescript-react-material-ui" for example. Our project started a set of components for Bootstrap v4 (and "react-bootstrap" can be an inspiration to look for).

Note that:

  • it is always better to import only one external component library
  • no external component library will fit a 100% to a project needs, leading us to develop other internal components

  • continue creation of bootstrap components

Other re-usable logic

Does every components existing in the JavaScript Bootstrap library should be written in PureScript? Basically no, two reasons:

  1. absence of logic: dumbest of the dumb vanilla components should remain vanilla. For example, what would be the point of creating PureScript Bootstrap component for a text node bearing a color variant (eg. "text-primary"). Keep It Simple Stupid here.
  2. declarative vs. implementation: If we look what vanilla Bootstrap offers for form inputs, we can see a plethora of great declarative CSS classNames ("form-control" to set a UI context, add "is-valid" to the DOM element to colorize every border and text in green, etc.). But if we take a look at what the React Bootstrap offers to the same effect, we see a profusion of intricated-but-yet-not-related components, mixing logic, limiting the possible implementations (ie. what happens if we write our vanilla HTML code differently?) As we can see in the "~/src/assets/sass/main/base/_form.scss" file, it is far better to just offer simple declarative CSS classNames. So YAGNI here.

Other non-related Bootstrap library component

  • <toast> component
  • <icon> using Google Material Icons, from one the Bootstrap recommended list
  • <blank-placeholder> (please refer to the "Placeholder" part of the "Component Cookbook" wiki)
  • <cloak> overly "react-suspense" simplified component with more UX features (please refer to the "Placeholder" part of the "Component Cookbook" wiki)
  • <reset> component + context provider for resetting a page
  • <role-control> component gateway regarding user roles

« 3.2 — CSS integration model             5 — Form validation »
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.