29 Matching Annotations
  1. Nov 2020
  2. 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.
  3. 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.