manutter51 / woolybear Goto Github PK

View Code? Open in Web Editor NEW

69.0 5.0 11.0 3.21 MB

Demo for Clojure Conj 2018

Clojure 96.60% HTML 0.33% CSS 3.07%

woolybear's Introduction

woolybear

A re-frame application demonstrating some principles of Atomic Design and reusable re-frame components.

Setup

This repository was initially created using the following command:

lein new re-frame woolybear +10x +re-frisk +routes

Adding Bulma

Here's how I added the Bulma CSS framework as a git sub-module:

Under the main repository directory, create a sass subdirectory, then cd into that directory and add Bulma as a git submodule so we can easily update it when/if needed.

$ mkdir sass
$ cd sass
$ git submodule add https://github.com/jgthms/bulma

Then add the sass/woolybear.scss file.

Adding `lein sassc`

Here's how I added the lein sassc plugin:

In the project.clj file, add the following

:plugins [...
          [lein-sassc "0.10.4"]]

:sassc [{:src         "sass/woolybear.scss"
         :output-to   "resources/public/css/wb.css"
         :style       "nested"
         :import-path "sass"}]

Note: You will need to manually run lein sassc once to rebuild your CSS file when you have changes. Your editor/IDE may have a way to set up a keyboard shortcut to make this easier.

Documentation

More detailed documentation is available here.

Development Mode

Run application:

lein clean
lein figwheel dev

Figwheel will automatically push cljs changes to the browser.

Wait a bit, then browse to http://localhost:3449.

Production Build

To compile clojurescript to javascript:

lein clean
lein cljsbuild once min

References

Re-frame: https://github.com/Day8/re-frame
Bulma: https://bulma.io

woolybear's People

Contributors

Stargazers

Watchers

Forkers

timotheosh nanomonkey speakertosystems erikpilz cswaroop-opensource bmkmanoj manojsingh1101083 rende11 villadiegofj cawasser jaremko

woolybear's Issues

Missing Dependencies

There seem to be references to some dependencies that aren't included in the repo which cause the Woolybear app to not compile.

For example:

woolybear.ad.catalog requires woolybear.packs.flex-panel, woolybear.packs.tab-panel
woolybear.ad.catalog.containers requires woolybear.packs.flex-panel

Is this intentional in that I'm meant to implement those packs myself?

P.S.
Sorry if this isn't really an issue and just a result of my inexperience with ClojureScript. I was intending to use your project as a learning platform in which I can explore atomic design, style frameworks, and ClojureScript + Re-frame - ending up with a neat little components catalog for future reference.

Questions

Sorry in advance for making this an issue; I'm not really sure how else to reach you, but I also think the following might be useful for the public domain.

Mark, great talk!

I've been using re-frame on/off for over 3 years now. It's a fabulous front end paradigm, and I'm glad someone decided to dedicate conference time to the topic.

I have never really been satisfied with any sort of reusable component scheme that I've invented or found in the wild. There seems to be an inevitable tax to be paid with respect to unidirectional functional components and reusability. The elm language and elm architecture have been debating this topic for a very long time. Some approaches out of that world satisfy the "infinite abstract reusability" problem (can achieve any N number of components without any component having "a place"), but at the cost of scattered state (no single app-db, as re-frame would have it). Some approaches out of the re-frame world can achieve the same goal but with what feels to me like too much manual effort or "hand-holding".

Your DRY approach to reducing handlers/subs is neat and seems like a step in the right direction to semi-autonomous components and low-effort reusability. However, something that immediately strikes me is how inflexible this might become over time. If each component is self aware enough to "know its slice in the db", it seems to be quite literally PLOP-oriented programming. To highlight a concrete problem: how do you handle the inevitable refactoring that stems from an evolution of an application (whether from changing requirements, better designs, better domain knowledge, etc.) if "places" are littered everywhere throughout the app? I find my app-db shape/schema changes quite regularly as the application evolves. Through judicious use of subscriptions and the great idea of inject-sub I am able to more-or-less keep any notion of "where" located to a single location (per component, or per feature). The proliferation of "wheres" everywhere makes me nervous, but the drastic reduction in boilerplate feels safer and less annoying.

Thoughts?