50 Matching Annotations
- Sep 2024
-
stackoverflow.com stackoverflow.com
-
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.
-
- Nov 2023
-
github.com github.com
- Sep 2022
-
github.com github.com
-
In particular, it allowed for organizing common traits (such as extensibility, or different ways of showing examples as schemas that can be mixed in to the main object definitions.
-
- Apr 2022
-
-
There are project layouts that put implementation files and test files together.
-
- Mar 2022
-
-
If you want to organize said migrations in their purpose you'll probably have a folder for the struture ones and another for the data ones.
-
not as good/useful as some other gem options/approaches, such as the one that adds a
data
method per migration, or that lets you tag with:post_deploy
, etc.
-
-
github.com github.com
-
-
db/migrate/core/user/
-
- Jul 2021
-
blog.appsignal.com blog.appsignal.com
-
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.
-
- Jun 2021
-
blog.viktoradam.net blog.viktoradam.net
-
This compatibility simply means that you can have a .githooks folder at the root of your project, where you can organize your individual hooks into folders.
-
-
shareup.app shareup.app
-
We’ve broken our project up into three different types of packages: apps which are preact apps intended to be bundled and deployed somewhere, modules which are plain npm packages for node/browsers and do not bundle their dependencies, and workers which are either Worker or ServiceWorker scripts entirely bundled up with no imports or exports. We don’t have to keep these three types of packages separated, but it helps us navigate around.
-
-
-
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.
-
- Apr 2021
-
stackoverflow.com stackoverflow.com
-
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.
-
- Feb 2021
-
www.schneems.com www.schneems.com
-
Another thing I don’t like: our asset behavior is decoupled from the assets. If you’re mucking around in your app/assets folder, then you have to first know that such a config exists, and then hunt it down in a totally different config folder. It would be nice if, while we’re working in asset land, we didn’t have to mentally jump around.
-
-
trailblazer.to trailblazer.to
-
An activity is a high-level concept to structure code flow
-
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 strikes when it comes to organizing business code.
-
-
github.com github.com
-
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.
-
-
github.com github.com
-
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.
Pretty weak arguments though...
- We could just as easily used a plain object or module to extract this for easy reuse and having it in only one place (avoiding duplication).
-
- Jan 2021
-
svelte.dev svelte.dev
-
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).
-
- Dec 2020
-
www.npmjs.com www.npmjs.com
-
Keep your patches colocated with the code that depends on them.
-
- Nov 2020
-
developer.ibm.com developer.ibm.com
-
in which business logic (JavaScript) is collocated with styles (CSS) and markup (HTML-like templating syntax).
-
-
stackoverflow.com stackoverflow.com
-
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.
-
-
guides.rubyonrails.org guides.rubyonrails.org
-
A resource route maps a number of related requests to actions in a single controller.
-
- Oct 2020
-
guides.rubyonrails.org guides.rubyonrails.org
-
This simplifies maintenance and keeps things clean by allowing related code to be grouped before inclusion elsewhere.
-
-
medium.com medium.com
-
withindex.js, we have a single source of truth, giving fine grained control on what we expose to the outside world.
-
import statements will become much smaller, as we will be importing stuff from less files. For example AbstractNode.js has only on import statement now, where it had two before.
-
The reason that this solves our problem is: we now have full control over the module loading order. Whatever the import order in internal.js is, will be our module loading order.
-
Here are few, real-life commits of refactorings that make use of this solution:
-
The crux of this pattern is to introduce an index.js and internal.js file.
-
Tags
- be specific
- list of examples
- main/key/central/essential/core thing/point/problem/meat
- +0.9
- circular dependency
- refactoring
- under my control
- control (programming)
- exports (functions/etc. exposed to outside world) (modules)
- concise
- specific examples
- advantages/merits/pros
- fine-grained control
- code organization: internal module pattern
- single source of truth
- key point
- having enough control over something
Annotators
URL
-
-
github.com github.com
-
-
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.
-
-
github.com github.com
-
In some cases, I could also create a component without any <script> tag at all. So in that way, I could actually bulk up the logic in one place if I could get some help from the #with block.
-
-
github.com github.com
-
Separately, I wondered about having a central registry of warnings, since they're a bit scattered around at the moment. That way, we could check that someone wasn't trying to ignore a non-existent warning.
centralized
-
-
-
I'm also persuaded by the arguments that it will be easier to track stuff down by co-location.
-
I also think this would be great in terms of colocation. If I need some intermediate result I no longer have to jump between script and markup.
-
I'm persuaded that co-locating just this one type of logic will be useful.
-
I like this, mostly because it allows me to write small components without creating another separate sub-component for holding the value simple computation. I get annoyed every time I need to create a component just to hold a variable, or even move the computation away from the relevant location. It reminds me of the days where variables in C had to be declared at the top of the function.
-
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.
Tags
- programming: multiple ways to do the same thing
- consistency
- uniformity
- idiomatic code style (programming languages)
- software development: code organization: where does this code belong?
- convention
- idiomatic pattern (in library/framework)
- advantages/merits/pros
- code organization: co-location
- good point
- strong conventions resulting in code from different code bases/developers looking very similar
Annotators
URL
-
-
-
When I say that my experience is that it means it's time to split up your components, I guess I mean that there tends to be a logical grouping between all the things that care about (for example) sqr_n, and in Svelte, logical groupings are expressed as components.
-
-
dylanvann.com dylanvann.com
-
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.
-
- Sep 2020
-
github.com github.com
-
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.
-
-
css-tricks.com css-tricks.com
-
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.
-
-
github.com github.com
-
Because of that, it's easy to end up in a situation where the styles for a given piece of markup are defined far away (in terms of number of lines) from the markup itself, which reduces the advantage of having styles and markup co-located in the first place.
-
-
github.com github.com
-
but adding logic to the <script> is unfortunate
-