Folders structure for functional code

[steida]

An app built with fp-ts contains a lot of small functions. How do you organize them? Utils? Model? Something else?

I used to use a models directory e.g. models/user.ts or models/workout because those small functions belong to the business model. Maybe it's probably the best approach. WDYT?

[grossbart]

One pattern I like to use are .extended modules as described here: https://jaspervdj.be/posts/2015-01-20-haskell-design-patterns-extended-modules.html

For example, instead of importing from fp-ts/Either, you could import from /vendor/fp-ts/Either.extended that could look like this:

/* /vendor/fp-ts/Either.extended.ts */
export * from 'fp-ts/Either'

export const getOrThrow = …

Lots of ways to name this, but the basic pattern of augmenting a module this way works well to accomodate small helper functions.

[edalex-ian]

That's an interesting idea, as currently I've just been creating simple files with the same name but in our tree - e.g. utils/Ord.ts - but these get modified with other non-fp-ts utils.

(Also interesting you have a getOrThrow for Either - I've been pondering adding one (rather the continually writing it out in full), but decided the reason there isn't one already is arguably it's against the FP grain. However seeing this makes me think I might just go and add it after all in an .extended module. 😉 )

[samhh]

I disagree with naming your modules according to a library, personally. I'd suggest something like this:

/
  app/
    etc
  lib/
    Number.ts
    etc

And Number.ts can contain:

export * from 'fp-ts/number'
export * from 'fp-ts-std/Number'

export const magic = 42

// etc

[tstelzer]

I disagree with naming your modules according to a library, personally. I'd suggest something like this [...]

I don't think the two approaches are mutually exclusive. One is for strictly extending a library module (e.g. extending the Option module with a helper), the other is for adding more generic functions.

I would add a third, which is domain-specific functions, which I tend to either co-locate with the domain modules, or gather in a top-level domain.ts, depending on the size of the application.

[JoshuaAmaju]

export * from 'fp-ts/number'
export * from 'fp-ts-std/Number'

export const magic = 42

So how do you handle conflicting function names in both packages?

[samhh]

How do you handle conflicting function names in both packages?

Unfortunately the best approach I know is to just list the exports manually for the smaller set.

export * from 'fp-ts/number'
export { foo, bar } from 'fp-ts-std/Number'

export const magic = 42