This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (3)
- # beginners (90)
- # boot (1)
- # cider (1)
- # cljdoc (23)
- # clojars (1)
- # clojure (91)
- # clojure-dev (8)
- # clojure-greece (1)
- # clojure-italy (17)
- # clojure-japan (1)
- # clojure-nl (6)
- # clojure-spec (4)
- # clojure-uk (89)
- # clojurescript (48)
- # core-async (5)
- # cursive (79)
- # datascript (1)
- # datomic (40)
- # duct (1)
- # emacs (7)
- # figwheel-main (2)
- # graphql (7)
- # jobs (5)
- # nyc (5)
- # off-topic (61)
- # other-languages (2)
- # parinfer (6)
- # re-frame (63)
- # reagent (131)
- # ring-swagger (6)
- # shadow-cljs (158)
- # spacemacs (14)
- # tools-deps (15)
I'm having an issue with Electron + re-frame,
Uncaught Exception: ReferenceError: React is not defined
Only thing that changed was updating to re-frame 0.10.5 so I could use re-frame-10x
it was working before with re-frame 0.9.2 as long as I installed React in my node_modules
@hiskennyness I had my stuff separated in subs / events / ... also for some time. But I looked lately into Vuejs and liked that complete separation of components. Stuff like a login dialog for instance almost always is the same across applications and I like to have it separated as much as possible.
I've always liked to keep stuff that is related close by each other in such a way that everything within a specific file is about one thing only. I did this same kind of subs/events etc separation too but with Java and Spring back in the days by creating packages called controller, service, dao etc, basically the same thing. This leads to gigantic files which serve gazillion use cases and when the application grows in size it gets harder to see the big picture. I mean, it isn't really a good thing that if you have like
OrderService with Spring and that
OrderService grows to be 3000 lines of code with 120 methods. Same thing with UIs and re-frame: if you end up creating
subs.cljs with 50 subscriptions regarding orders then it gets hard to see the forest from trees.
To me it makes much more sense to split stuff based on the use case or in the case UIs based on components. So instead of creating
order-subs.cljs or similar create a file called
edit-order.cljs which contains the necessary subs, event handlers and so forth. Then when you will (inevitably) find you are duplicating code then take that code out in a more generic form.
naturally there will be generic subs/event handlers etc too but those should be the exception not the norm since that is the nature of UIs in general
one should strive to reusing components, not reusing subs/event handlers, if one goes for the first then you'll end up also reusing the latter
@niklas.collin I like your answer. It makes sense. To make things clear I had subs / events per entity like books/subs and books/events. But still, it seems so artificial. I will try a more componentized approach now and see how it works out.
first people separate by framework concept, then the separate by entities and then finally start to separate based on UI components
Good thing with componentization is that it forces the programmer to think about reusing stuff. For example, you have to list items. Should you just dump
[:ul (for [x lots-of-xs] [:li x]] or should you actually build a component out of listing stuff?
It's a trivial example but a valid one. Suddenly you need to give user power to sort the items. Then you need to handle paging. Then you need to be able to sort by multiple values within entities listed. And then you end up into same situation somewhere else in the UI
On the other hand sometimes I overengineered stuff just for the sake of not replicating things.
you can extrapolate that to previous example: if you need to list and sort in two places, keep em separate. But if you find you need to add a third common functionality then create a generic component
Just need the discipline to follow through. It's interesting how much of an emotional task programming is. I could not say that I was able to follow that rule every single time. But instead decide different from day to day depending on how much time I have, is it a professional project or a hobby project. Is there a deadline to fulfill.
deadlines force us to make technical debt and not do that componentization when it would be the logical time to do that since it is faster to do yet another copy of the logic than to make the more generic version for that
Thats ok, my PM would say, I need that feature in this release, because in the release meeting I need something to show. Tech debt release cannot be shown. 😄
Yea, but I need to be fair, 2 years ago we had one release cycle solely for tech debt (which is 6 months for us)
I'm usually the lead dev / architect and I say back "Sure, can do. But then we'll spend the next sprint fixing the shit you forced us to do and you'll have zero things to show in sprint demo. Which one you prefer?"
and if he refuses that and forces to push for features then I make it clear to other people that we are piling on tech debt and it is not the fault of the dev team and we need to act on this before we need to do a full sprint (or god forbid, 6 months) of tech debt removal
every now and then I've got a customer who understands this. Usually when this happens we end up going under budget and getting things done before the final deadline
Yea. I work on a product that is almost 10 years old now. In the beginning the team decided to use visual representations as "data structure". So we do rules development. A rule consists of a LHS and RHS. you can perfectly show this as a table consisting of rules. So thats what our first data strucuture was. A Project consisting of tables. Later on we introduced trees. So the next data structure was a Tree. All saved in XML files. And then a lot of work doubled because instedad of having a group of rules that is decoupled from its UI representation we had trees and tables and both of them needed validation and stuff. This did and does cost so much time and results in a lot of double work or features only being implemented in in trees or tables, etc. I have been opposing this, but in a team of 14 people one two were able to see the consequences and unfortunately it was not our team lead and not our PM
it's the classical management problem, managers (which lead devs are more or less really, just in a different form) exist so that they can be responsible of something. And when there's responsibility there's pressure to hold on to that responsibility. And when you have several responsibilities as a manager you tend to focus on the one that will blow up to your face sooner than those which blow up later - even if those which will happen later are going to be a LOT more painful when that happens
it's in human nature and requires a lot of discipline to take shit to your face in short term so that you and your team can excel on the long term
I tend to do that and because of that I've suffered one burnout during my career already
really great managers and leaders are those who can take that short term beating, keep together while doing that and then deliver in a great way on the long term
I didnt even mean it in the sense of good / bad managers, just that they couldnt see how much of a problem this might become. Time and feature wise.
@sveri 6m sprints! And just yesterday I found https://twitter.com/iamdevloper/status/1018929687450484739 to be on the nose and funny
@U8ZQ1J1RR No, we do 6 months releases, currently at 1 week sprints which are pretty ok, given we do retros and demos only every 3rd week
Is there a way to use re-frame with devcards? Would I need to mock subscriptions and the like? Perhaps I should only be using subsciptions on my higher level components and passing that data down to pure reagent components which can be used in devcards?
There's been talk of making a pure re-frame, but currently the model isn't really compatible.
If a component subscribes to something, there's really no way to give multiple instances of it different paths or branches of the app-db
Hmm, so it might make sense for me to have a single instance of these components with the single instance of re-frame? It might be a little weird to have them updating eachother though.
I did see that there's been some recent progress with https://github.com/Day8/re-frame/blob/master/docs/EPs/002-ReframeInstances.md
Well, the draft did get a commit, yes, but it was mostly slight rewording. Some new ideas recorded too, but there's been no work on an actual implementation that I know of. The recently mentioned attempt has been dormant for a year
Ah, ok. Thanks for that. The only other place I've seen to track it is https://github.com/Day8/re-frame/issues/137 which hasn't had any progress recently.
I believe om.next has a cursor paradigm that fits well, but I haven't looked into that in over a year, and never in much depth
Of course the bubble bias is at work here, but it seems to me like re-frame is becoming more and more common
I wasn't a big fan of the way
om.next did things, and it seems to be largely abandoned by David Nolan.
I did quite a bit of the cursor style structuring with
rum, but it became a bit unweildy after a while. Specifically when trying to combine different sections of the tree.
re-frame's methodology up until now, though devcards and better testing are pretty important to me.
@mikethompson, I see there's been some recent progress with https://github.com/Day8/re-frame/blob/master/docs/EPs/002-ReframeInstances.md What still remains to be done with this? Can we expect anything in the forseeable future?