Fork me on GitHub

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


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


Electron main btw


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


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


yeah, that is usually the second step 🙂


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


last one is the only that truly scales in my opinion


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


thats true


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




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


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


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


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


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.


oh yes, deadlines are synonymous to bacteria


they infect stuff


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


but that leads to linear progression instead of exponential


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


yup, I totally know what you are talking about


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


it depends on people if this works or not


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


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


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


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


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


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


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


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


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.


@gadfly361 okay, thank you!


@sveri 6m sprints! And just yesterday I found 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

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?


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

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.


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 which hasn't had any progress recently.


I believe 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

Garrett Hopper19:07:19

I wasn't a big fan of the way 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 What still remains to be done with this? Can we expect anything in the forseeable future?