Fork me on GitHub
#component
<
2016-01-05
>
drusellers02:01:34

How are people managing large component maps

drusellers02:01:44

is everyone just keeping it in one big file?

sveri13:01:42

@drusellers: What exactly do you mean with "large component maps"?

drusellers13:01:26

@sveri: as I build out my application I’m seeing a pattern of components needing to be built - an endpoint / database calls / core logic that needs the database etc

drusellers13:01:56

if my application has 20 major features x 3-4 sub components per piece that would be 60 to 80 entries in the system map

drusellers13:01:08

then 60-80 using vectors

drusellers13:01:19

that just seems large to me

sveri13:01:15

When I started using component I also noticed that the system map is getting larger and larger. However, I got accustomed to it and never noticed any drawbacks. So I don't really know if this is a problem or not, as long as it does not convolut my application logic, I am fine with that.

sveri13:01:42

I mean, it's just a map with simple data, compared to other data that might flow / stay in your application it is nothing, usually

drusellers13:01:49

absolutely a fair point

drusellers13:01:57

i’m just new and have these random questions. simple_smile

drusellers13:01:13

i don’t want to make random assumptions.

sveri13:01:39

Yea, like I said, starting out I had the same feeling, especially when I tried to understand the structure and see if I built them right, this is hard to do when the map is so large

drusellers13:01:03

how do you structure your map? i have like accounts (core logic), accounts-endpoint (compojure), accounts-db (database access)

sveri14:01:10

I structure them component wise, so one component for all compojure routes for instance, one for the server, one for the database

sveri14:01:34

But, splitting them could also be an option, if it fits you better...

drusellers14:01:59

I’d say its a legacy of how I tend to think of code from C# where I could just type scan in all of these little components

drusellers14:01:27

i can see the value in one big endpoint with the way compojure does routing

drusellers14:01:54

so if you have one database component what does that look like for you?

drusellers14:01:04

(get-entityx db args)

drusellers14:01:10

(get-entityy db args)

drusellers14:01:19

and you just have 300 of those in the db.clj?

sveri14:01:03

this is my database component, in the case of korma it just opens a db connection: https://github.com/sveri/closp/blob/master/resources/leiningen/new/closp/clj/components/db.clj

sveri14:01:30

the thing with korma is, it just setups a default connection which can be used everywhere, so I dont even need to pass it around, so maybe this is a bad example

sveri14:01:26

you can see them being passed to my routes

sveri14:01:45

not sure if this answers your question, but this is how I always use them, so I have rather large components

drusellers14:01:54

it helps, just seeing examples

drusellers14:01:22

moving from a language that doesn’t like large code files to clojure which prefers them is a mental shift

drusellers14:01:46

and I just see my system map growing and growing

drusellers14:01:00

but my patterns are coming from C# and i’m trying to find my way into clojure patterns

drusellers14:01:23

and its weird seeing functions with all of these params still. 😜 (still thinking in method land)

sveri14:01:51

It always helped me thinking in terms of something that can be start and stopped during development. So, when I dont need to restart single routes, I can keep them all in one component. But if I have extra routes for websockets for instance, they could be put into their own component

drusellers14:01:41

yeah, i have the reloaded process working and that is super nice

sveri14:01:42

Also you dont need to have large source files, I am not sure if there is a best practice on that already in clojure. Keeping them small surely is a good thing

drusellers14:01:06

it helps me, but then i end up with this huge :require in my system map

drusellers14:01:16

I need to find a way to better compose these things

sveri14:01:39

I think you might try several approaches and see how they fit you

drusellers14:01:28

fair enough. simple_smile

drusellers14:01:10

Thank you very much for taking the time to chat through this with me. You have definitely helped me come to terms with a few things. simple_smile

drusellers14:01:17

and thank you for sharing your code

sveri14:01:49

No problem, if you have more questions, just go ahead, talking about things often helps simple_smile

Lambda/Sierra15:01:39

Remember that systems are just records, which are maps. If you have groups of components you can merge them together.

Lambda/Sierra15:01:52

I like to define using dependencies in the component constructors, and only override them in the system map if necessary.