This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-19
Channels
- # admin-announcements (1)
- # beginners (26)
- # boot (6)
- # cider (14)
- # cljsjs (29)
- # cljsrn (19)
- # clojure (87)
- # clojure-austin (5)
- # clojure-belgium (10)
- # clojure-brasil (2)
- # clojure-dusseldorf (15)
- # clojure-greece (17)
- # clojure-russia (51)
- # clojure-sanfrancisco (4)
- # clojure-sweden (20)
- # clojure-uk (31)
- # clojurescript (111)
- # core-matrix (2)
- # cursive (9)
- # datascript (15)
- # datomic (41)
- # dirac (1)
- # emacs (8)
- # flambo (1)
- # funcool (4)
- # hoplon (72)
- # lein-figwheel (3)
- # off-topic (2)
- # om (79)
- # om-next (2)
- # onyx (17)
- # other-languages (16)
- # re-frame (62)
- # reagent (26)
- # remote-jobs (1)
- # rum (3)
- # spacemacs (5)
- # untangled (120)
@lewix: it sounds like Luminus should be your starting point - http://www.luminusweb.net/
Not for the language, but if you are seeking some overall structure about getting started with a web app in clojure
Looking for some guidance with a larger app - https://github.com/Day8/re-frame/wiki/A-Larger-App - If I’ve got multiple db.cljs files setting up multiple databases, as suggested, how do you switch between those when using different “panels”. Is anyone here actually using that approach? I can’t seem to find any examples online and my experiments are failing me a bit…
I’m not fully understanding how the DB is stored by re-frame. Can I just fire off a new handler which returns my new DB and everything switches over to that?
@escherize: Have you seen the suggestion for larger apps here? https://github.com/Day8/re-frame/wiki/A-Larger-App
I believe panel1.db namespace would just be functions that are for panel1 that operate on the db.
Oh, ok. I’ve not come across db-functions kept in that db namespace in any examples, is that a common approach?
I'd probably do something like this:
(r/atom {:panel-1 {:name "George"}
:panel-2 {:name "Oren"}})
so the handlers ns was about 600 loc - but It never bothered me enough to split them up.
Anyway that's just housekeeping imo - the key to reframe is that you have handlers that are (ideally/usually) pure functions operating on a single db, and returning new versions of it.
It’s not the size, per se, this app is a collection of different utilities for our admin team to work with. Was getting annoyed with the handlers all being in one spot, so started to give them virtual namespaces, then saw that wiki article but couldn’t follow the splitting of db.cljs
call it register-signup
or signup/register
doesn't make a big difference imo. When it comes to panelN/db.cljs
I would think db.cljs could require panel[1-N]/init and merge the initial data together as it saw fit.
@heeton: the different db.cljs
generally just hold schema. or perhaps initial values. Stuff related to the model/database. They do not actually contain a database itself. There is only one of those and that's hidden away in re-frame itseld.
For example: https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/db.cljs
@mikethompson: That’s what I was trying to ask about. If you have multiple db namespaces, does that imply that you’ve got different sets of initial values that you’re swapping the DB out for as you switch panels?
It depends. But you probably wouldn't be swapping dbs. You would be more likely updating part of it.
(ns db.init
(require [panel1.db :as panel1]
[panel2.db :as panel2]
[panel3.db :as panel3]))
(defn init []
{:panel-1 (panel1/init)
:panel-2 (panel2/init)
:panel-3 (panel3/init)})
(register-handler
:init-db
(fn [& _]
(if-let [frozen-state (find-app-db-in-local-storage)]
frozen-state
(init))))
If it was necessary, you might be dispatching various initialize events in here: https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/core.cljs#L30-L34
Usually I check local storage before init-ing the DB, since I tend to save to ls on "important" events.
Realising I can actually swap out the entire DB contents for a new panel’s #init’ed data too
(right now, the panels are totally separate) But that’s probably not a good long-term idea because we’ll want to add some sort of top-level data at some point
I think a problem re-frame dodges which is shared by a lot of clojure, is updating nested data inside atoms can be tough.
So @escherize you do all the database manipulation stuff directly in your handlers. Know of people just deferring to db namespaced “updater” functions? Has anyone talked about that approach and if it’s good or needless?
I know that people use that. I was working on that large project by myself. I could see if I had a team working on it how I'd like to split things up, since it'd make it easier to see what has been changed/added.
If I'm working on the payments page, then I dont care if you change most anything in ourproject.signup/*
.
Is there any known method or util/library to view your entire app-db in object form? Like print it out in the js console and be able to look at each section?
@mattsfrey: I use https://github.com/yogthos/json-html myself
It comes with a CSS file to style the results, and then just spits out a big table of html when you provide your db value.
@mattsfrey: https://github.com/Day8/re-frame/wiki/FAQ#5-how-can-i-inspect-app-db
damnit @mikethompson 😐
1 sec - adding to resume: http://take.ms/73unv
Famous!