Is it possible to introduce a web-inspired folders structure?

Hello!

I am relatively new to Clojure and ClojureScript world and feel a little confused about my possibilities in setting a convenient folders structure.

In JavaScript/React world, where I have arrived from I, can create conveniently nested folders for a single component in the following way:

src
  components
    molecules             // Following Atomic Design Methodology.
      Search
        index.js          // This one for convenient imports outside.
        Search.tsx        // This is where the main code is.
        Search.css        // Styles for Search component.
        Search.test.tsx   // Tests.
        Search.stories.js // File for creating components page in Storybook.
        subcomponents
          LensIcon
          ...

In ClojureScript projects, I’ve seen the structure was quite primitive: just the list of cljs files in src/pages with the mix of markdown, logic, and styles. Specs were in a separate folder copying at some point the structure of the components folder.

I’ve tried to implement what I’ve seen in the JS world but faced some obstacles: folders are treated as packages, and thus my imports are getting longer. Instead of writing (:require [app.components.molecules.search :as search]) I need to write (:require [app.components.molecules.search.search :as search]).

Is it possible to implement the folders structure I try to? Or is there may be some other convenient way that I do not know about and should become aware of?

How about app/components/molecules/search.cljs and app/components/molecules/search/style.cljs?

1 Like

This looks like a solution to me. So there is no “default” entrance file for a package like index.js in JavaScript case, but I can create an interface for my component in the parent directory?

Clojure really doesn’t care what namespaces are named or how they are nested. It looks like a hierarchy but from Clojure’s point of view it might as well be a flat list. There’s no concept of a default or parent namespace for instance.

So you’re free to organize things however you like. What @ShiTianshu suggests is a common convention.

  • my.component
  • my.component.foo
  • my.component.bar

Libraries will often have a core namespace which is consisted the top level

  • libname.core
  • libname.foo
  • libname.bar

Or sometimes you see a split between a namespace that provides the public interface, and one with internal implementation stuff.

  • hello.world
  • hello.world-impl

It’s really up to you.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.