Update wording to include prop behaviour

[jesseskinner]

In regards to #4442, this adds wording to explain that props are set to undefined when they are removed by the consumer.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR relates to an outstanding issue, so please reference it in your PR, or create an explanatory one for discussion. In many cases features are absent for a reason.
• This message body should clearly illustrate what problems it solves. If there are related issues, remember to reference them.
• Ideally, include a test that fails without this PR but passes with it. PRs will only be merged once they pass CI. (Remember to npm run lint!)

Tests

• Run the tests tests with npm test or yarn test)

[mindrones]

Apart from the suggested change, it would be good to merge to me.

[jesseskinner]

@mindrones Not sure about "instancing" as a verb. What about: "It will be used if the component's consumer doesn't specify the prop when the component is instantiated." ?

[jesseskinner]

Alternatively, "It will be used if the component's consumer doesn't specify the prop when instantiating the component." ?

[mindrones]

Sorry wrote in a hurry (also not native :), they're both OK to me, thanks!

[mindrones]

Re: #4442 (comment)

I'm not sure if we want to add that kind of suggestion in the reference. I tend to agree, but I'd prefer using something like:

export let prop;

$: prop = prop || 'default';

[jesseskinner]

@mindrones Won't that cause a warning in development though?

[mindrones]

It would, but I'm not sure I'd want to see the form you suggested in the docs, although correct it's pretty long. Since this is a personal opinion I'd like to hear from others too :)

[jesseskinner]

@mindrones Agreed, this whole section is getting pretty long as it is :)

Hm I rebased master in my branch and now all those extra commits are here. Not sure what I need to do to fix it if anything.

[mindrones]

Hm, not sure.. I'd try something like this:

• copy the current changes in that branch somewhere locally,
• locally, delete patch-1
• checkout master, pull
• checkout a new branch patch-1 from master
• apply the change in this branch and commit
• git push --force

[Conduitry]

Don't worry about all the extra commits - this will be squashed anyway when it is merged.

I think this clarification sounds reasonable, thanks!

[tanhauhau]

export let prop;

$: prop = prop || 'default';

Probably we should add a tutorial or guide on recommend how to provide a fallback value to props if it is undefined (technically falsey)?

[mindrones]

@tanhauhau agree, this would be good for a mini guide, see also #4442 (comment). Only problem the snippet suggested by @jesseskinner although correct isn't very attractive/sveltey, while the above one will give warnings.

[StagnantIce]

If you dont want dublicate your defaults, will be better like this:

export let prop1 = 's';
exprot let prop2 = [];

const defaultValues = {prop1, prop2};

$: prop1 ??= defaultValues.prop1;
$: prop2 ??= defaultValues.prop1;