A better way for accesing globals like $$props

[samuelgozi]

Is your feature request related to a problem? Please describe.

Right now when you need to access props programmatically you need to use the $$props var, and that is not recommended by the docs, I assume because its a private variable, and that is understandable.

Also, I saw that the addition of $$slots is stalled due to lack of a good solution that will replace the $$ pattern:
#2106

Describe the solution you'd

I think that maybe instead of using the prefixed $$ globals, a more "natural" solution could look something like this:

import { slots, props, parent } from '@component';

Svelte will look for imports of @component or any other path or name that doesn't really exist(for example svelte/component), and then do some kind of dependency injection.

I believe that this way is easy to understand because the used just does an import, like he is used to do in virtually any JS library/framework now a days.

And since this is normal JS syntax, stuff like this could be done:

import { slots as otherName } from '@component';

And there is nothing new to learn, its just regular JS.

And adding new(or alternative) functionality would be easy, like maybe(hopefully) props defaults with validation? (ignore the probably bad naming)

import { propsSettings } from '@component';
propsSettings = {
  propName: {
    required: true,
    type: String
  }
}

EDIT:
This can also replace the $: syntax for computed properties.
In my opinion using $: looks and feels like a hack, I know its valid syntax, but it doesn't feel right(IMO).

So an alternative(doesn't have to replace anything) could be:

<script>
import { computed } from '@component';

computed = {
    propName() {
      return someThingDynamic;
    }
};
</script>

<div>{ propName }<div> // or computed.propName

I know this is not perfect, but it is easier to understand and to reason about than $:.
You can use whatever name you'd like, and it should be easy to implement because we with the import we are essentially telling the compiler which variables in our code should be injected, and with which name.

It also takes a lot of the magic out from the current solution, and there should be no problem implementing this incrementally.

How important is this feature to you?

Very, I think it is much cleaner and simpler than the current way of doing stuff.

[Conduitry]

$$props isn't discouraged because it's a private API (it wouldn't be mentioned in the docs if it were a private API) - it's discouraged because it's invalidated whenever any prop changes, which means you lose the benefit of only having necessary things recomputed.

I also wouldn't say that $$slots stalled because of the inability to settled on a name. It's stalled because of the finite amount of volunteer time available, and the importance of other things. The comment in that issue about not relying on the $$-prefixed variables is referring to the $$-prefixed properties on a component instance, which are part of the private API and subject to change at any time.

Magic imports (like from @component) is something that's come up many times, and isn't something that we're interested in having, for a number of reasons. See e.g. the conversation in #2746.