Rails' observers were partly inspired by aspect-oriented programming -- they're about cross-cutting concerns. If you're putting business logic in observers that is tightly coupled to the models they're observing, you're doing it wrong IMO.

This works nicely wherever we show authors, but after we deploy to production, the folks from other parts of the world won’t get notified anymore about their songs. Mistakes like these are easy to make when using concerns.

A litmus test on whether an option belongs to adapter config or kit config, would be to ask whether the option becomes irrelevant when you switch the adapter to static.

CSS seems like the right place to put visual information. On the other hand, few would argue that image "src" should not be specified as an attribute and the height/width seem as tied to the binary image data as the "src" is.

Whether this is the life-cycle of a <user> entity or just a sign-up function, it has to be defined and coded somewhere.

Trailblazer extends the conventional MVC stack in Rails. Keep in mind that adding layers doesn't necessarily mean adding more code and complexity. The opposite is the case: Controller, view and model become lean endpoints for HTTP, rendering and persistence. Redundant code gets eliminated by putting very little application code into the right layer.

ActiveInteraction plays nicely with Rails. You can use interactions to handle your business logic instead of models or controllers.

Why is all this interaction code better? Two reasons: One, you can reuse the FindAccount interaction in other places, like your API controller or a Resque task. And two, if you want to change how accounts are found, you only have to change one place.

It must be called during the component's initialisation (but doesn't need to live inside the component; it can be called from an external module).

In my opinion, deleting a user is not a function executed by an item on itself but is a function done by the holder of the array. So in your case you would be better of moving the deleteUser up to App.

Yeah I see what you're saying. In my case, I had a group of classes that relied on each other but they were all part of one conceptual "module" so I made a new file that imports and exposes all of them. In that new file I put the imports in the right order and made sure no code accesses the classes except through the new interface.

it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.

Keep the local state isolated.Think about which state is local to a particular UI representation — and don’t hoist that state higher than necessary.

I took the same approach with _layout.svelte and not just for the svelte-apollo client. Except I put all of that setup into another module (setup.js) and imported from _layout. I just couldn't stomach having all that code actually in my _layout file. It's for layout, supposedly, but it's the only component that is a parent to the whole app.

I got this working by using _layout.svelte as the point to initialise and set the Client we can then use getClient in each route that uses this layout.

there is one major weakness to this approach and to scoped CSS: organization gets very hard – you end up with styles everywhere!

Keeping the CSS with the HTML for organization may have value however.

but adding logic to the <script> is unfortunate