50 Matching Annotations
  1. Sep 2024
  2. Nov 2023
  3. Sep 2022
  4. Apr 2022
  5. Mar 2022
    1. 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.
    2. 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.

  6. Jul 2021
  7. Jun 2021
    1. 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.
  8. Apr 2021
  9. Feb 2021
    1. 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.
    1. 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.
    1. ActiveInteraction plays nicely with Rails. You can use interactions to handle your business logic instead of models or controllers.
    2. 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...

      1. 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).
  10. Jan 2021
  11. Dec 2020
  12. Nov 2020
  13. Oct 2020
    1. This simplifies maintenance and keeps things clean by allowing related code to be grouped before inclusion elsewhere.
    1. withindex.js, we have a single source of truth, giving fine grained control on what we expose to the outside world.
    2. 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.
    3. 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.
    4. Here are few, real-life commits of refactorings that make use of this solution:
    5. The crux of this pattern is to introduce an index.js and internal.js file.
    1. 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.
    1. 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.
    1. 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

    1. I'm also persuaded by the arguments that it will be easier to track stuff down by co-location.
    2. 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.
    3. I'm persuaded that co-locating just this one type of logic will be useful.
    4. 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.
    5. 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.
    1. 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.
  14. Sep 2020
    1. 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.
    2. 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.
    1. 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.