Fork me on GitHub
#re-frame
<
2018-07-19
>
caleb.macdonaldblack02:07:10

What are peoples thought on storing js objects in app-db?

baritonehands03:07:32

I'm having an issue with Electron + re-frame,

Uncaught Exception:
ReferenceError: React is not defined

baritonehands03:07:58

Only thing that changed was updating to re-frame 0.10.5 so I could use re-frame-10x

baritonehands03:07:45

it was working before with re-frame 0.9.2 as long as I installed React in my node_modules

baritonehands03:07:49

Electron main btw

baritonehands05:07:04

Figured it out, was able to upgrade to latest reagent, react, etc

sveri09:07:51

@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.

Empperi11:07:22

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.

Empperi11:07:03

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

Empperi11:07:46

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

sveri11:07:13

@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.

Empperi11:07:33

yeah, that is usually the second step 🙂

Empperi11:07:55

first people separate by framework concept, then the separate by entities and then finally start to separate based on UI components

Empperi11:07:21

last one is the only that truly scales in my opinion

Empperi11:07:21

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?

Empperi11:07:41

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

sveri12:07:30

thats true

sveri12:07:00

On the other hand sometimes I overengineered stuff just for the sake of not replicating things.

Empperi12:07:18

definitely

sveri12:07:26

But I think components is not the same as generic functions.

Empperi12:07:26

that's why there is the golden rule of generic stuff

Empperi12:07:35

if you need to do it twice, do not try to make it generic

Empperi12:07:47

if you need to do it three times, then it's time to refactor

Empperi12:07:39

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

sveri12:07:09

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.

Empperi12:07:36

oh yes, deadlines are synonymous to bacteria

Empperi12:07:41

they infect stuff

Empperi12:07:46

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

Empperi12:07:57

but that leads to linear progression instead of exponential

sveri12:07:43

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. 😄

Empperi12:07:00

yup, I totally know what you are talking about

sveri12:07:32

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)

Empperi12:07:54

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?"

Empperi12:07:17

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

Empperi12:07:35

it depends on people if this works or not

Empperi12:07:46

when it doesn't the end result will almost always be a shobby piece of crap

Empperi12:07:24

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

Empperi12:07:52

due to exponential speed up in development when the foundations start to be in place

sveri12:07:54

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

Empperi12:07:37

yup, you can't do squat as a normal developer if your lead doesn't hear you

Empperi12:07:03

as a lead dev myself I can understand the viewpoint of your lead (or at least guess)

Empperi12:07:51

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

Empperi12:07:17

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

Empperi12:07:46

I tend to do that and because of that I've suffered one burnout during my career already

Empperi12:07:44

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

Empperi12:07:39

managers looking only for quick wins are always - and I mean always - bad managers

sveri14:07:03

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.

Tommy15:07:41

@gadfly361 okay, thank you!

Hukka15:07:22

@sveri 6m sprints! And just yesterday I found https://twitter.com/iamdevloper/status/1018929687450484739 to be on the nose and funny

sveri15:07:09

@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

Garrett Hopper18:07:57

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?

Hukka19:07:25

There's been talk of making a pure re-frame, but currently the model isn't really compatible.

Hukka19:07:57

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

Garrett Hopper19:07:35

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.

Hukka19:07:09

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

Garrett Hopper19:07:41

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.

Hukka19:07:58

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

Hukka19:07:53

Of course the bubble bias is at work here, but it seems to me like re-frame is becoming more and more common

Garrett Hopper19:07:19

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. I've liked re-frame's methodology up until now, though devcards and better testing are pretty important to me.

Garrett Hopper19:07:15

@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?