(v2 vs. v3) No access to variables or this in imported functions.

[arxpoetica]

This came up from a question about the ability to access this in v2, but there's no comparable way in v3 (as far as I can tell).

Concrete comparison:

v2

https://svelte.technology/repl?version=2.16.1&gist=a1426a78ddf3e474fd0dae30abff7ac4

vs.

v3 (broken)

https://v3.svelte.technology/repl?version=3.0.0-beta.15&gist=eb712b331570406a8a717015f689f3bc

We can fix it with stores:

https://v3.svelte.technology/repl?version=3.0.0-beta.15&gist=039449c2c97cd95e88b10c813e97b55f

Or a rather convoluted methodology:

https://v3.svelte.technology/repl?version=3.0.0-beta.15&gist=cdae86f27a17171c74ee9a8449d9a495

But these solutions are not as self-containing as v2 was. What's missing is DRY importable functionality that can act on the component itself, and not external stores.

[pngwn]

Since we aren't dealing with a simple object anymore (where this makes more sense), the idea of an imported function acting upon the component doesn't make any sense, those values aren't in scope. If you want this kind of behaviour then stores are indeed the way to go. We don't really need to sacrifice anything to achieve this, as far as I can see. Just use a store value instead of a local value.

You could achieve an importable isChanged function by doing something like this: REPL

Edit: Or you can do something a bit crazier like this

[arxpoetica]

The problem with stores is they are one use only, and aren't shareable across DRY functions that are meant to be used in multiple instances. Functions enclose scope per instance, in other words. Stores break that mold.

This is also solvable by just passing and returning properties from functions, which is how native JS works. I'm just noting there's a difference between v2 and v3 in this regard (which is causing me a minor upgrade headache, requiring some basic app rewiring). If this change in philosophy / approach has been discussed elsewhere, I'll be happy to close this issue and read up on those specific changes. I'm just not aware of where the discussion took place.

Thanks.

PS: @pngwn I'm not trying to sideswipe your answer; you provided some good REPL answers. I'm just interested in the discussion about "is this an oversight" in v2 -> v3 changes, or is it deliberate, and what's the thinking behind this breaking change.

[pngwn]

Export the return value of the function in one of the examples I provided in the module itself and then the same store is available to every component that imports (the code would need to be modfied to actually work, of course). Obviously if you want different components to register different values with the 'store' and run checks against that then you'll need to add that logic in the function itself.

There has been a clear change of philosphy here, I think that is clear from the fact that there is no this anymore, so instead of using objects, mixins, methods and this, people will need to use closures and explicitly pass values around.

I'm certain this isn't an oversight, it was one of the design goals to encourage simpler patterns. You will be able to achieve the same things for the most part but the way we go about it will be different. We no longer have access to the instance anymore (that wasn't an accident) so the patterns we use will need to change.

[tivac]

I currently use the setup hook to get access to the component constructor so that my components can all register themselves into a component library that our testing system knows how to use. I haven't had a chance to investigate how to do that yet in V3, but hopefully it's still possible or I'm going to have to rework our entire testing infrastructure :(

[arxpoetica]

Okay, @pngwn I'm satisfied with the idea that it's intentional. I'll close.

[stalkerg]

@tivac I suppose it's bound to #779 I also need it.

[tivac]

@stalkerg I eventually opened #3010 because I still think this is missing functionality in v3. 乁( •_• )ㄏ