Reorganize / refactor repository

[AwaitFuture]

problem:

• many like ideas are scattered across a variety of directories
• test cases are in the same directory as a production code

solution:

• create some generalized directories, suggested directory structure:
  • Specs: any file describing a new type and its storage
  • Stores: any file describing a new storage table
  • subscriptions: any file parsing rich configuration and inserting it into the storage table
• test cases moved to their own directory

[rupurt]

Hi @AwaitFuture,

Thanks for the PR but I don't want to go down the path you've proposed. No doubt the structure can be improved and I'm all for aliasing where it makes sense but it's generally structured this way on purpose. The concerns aren't encapsulated as much as I'd like and I've been meaning to refactor some stuff along the lines of phoenix contexts but I haven't got around to it. e.g.

{:ok, new_head_subscriptions} = Slurp.NewHeads.Subscriptions.from_config(blockchains)

becomes

{:ok, new_head_subscriptions} = Slurp.NewHeads.subscriptions_from_config(blockchains)

many like ideas are scattered across a variety of directories

My preferred approach to code organization is by component/concept as I feel like it indicates coupling and makes refactoring easier by not having to jump around the hierarchy as much.

test cases are in the same directory as a production code

I prefer when the unit test file is siblings with the code under test as it makes finding the tests and refactoring easier, especially as a code base grows in size. I realize this is non-standard in Elixir but I want to use this project as a test bed to see if it's possible and identify the rough edges.

Specs: any file describing a new type and its storage

This is an overloaded term in Elixir with dialyzer. What does it mean in this context? Is this where all structs would live?

Stores: any file describing a new storage table

I prefer not to organize code by kind as I find it doesn't scale in larger code bases

subscriptions: any file parsing rich configuration and inserting it into the storage table

Hydrating domain objects is not the intention of the noun subscriptions. It's meant to indicate a stream of something that will be received e.g. event logs, new heads (in the future transactions). I feel like it doesn't make a heap of sense to namespace Slurp.Subscriptions.Blockchains as you don't subscribe to it. You would subscribe to the event logs, new heads or transactions.

[AwaitFuture]

Understandable, what is your preferred form of code organization? it seems like its by component. Ill avoid trying to reorganize things in the future. I was trying to add in some new features, and found myself asking questions on why things were organized the way they are.

[rupurt]

By component is my preferred method of code organization

[AwaitFuture]

understandable; I dont think I understand the organization of the repository as it stands then.