Debug Tag

[GarrettGeorge]

Re: Issue #1635

Currently don't have a test case for nominal output, but that's planned for tomorrow night.

Just wanted to submit the PR so I could go to bed + get some feedback on it. Went with the {@debug _ } to represent "debug all changes" which may or may not be something we want. But I added it anyway just to give an idea of what it looks like currently.

[Rich-Harris]

Nice! I think the 'debug all changes' version should just be {@debug}.

One small problem with extending from Tag — it adds expression dependencies to the block. This causes updates to happen, which would mean that in a situation like this...

{#each things as thing}
  {@debug somethingElseEntirely}
{/each}

...the debugger would trip for changes to somethingElseEntirely even if things hasn't changed (meaning that ordinarily that code wouldn't get reached). I think it probably needs to be a standalone class.

Also, Tag assumes a single expression; I think we probably need DebugTag to have an array of expressions, so that we can do {@debug foo, bar, baz}.

[GarrettGeorge]

For {@debug}, it I detect would it be bad practice to inject _ or something else maybe _svelte_debug_ before the } and then read the expression normally. Obviously that would mean _svelte_debug_ would need to be validated as a “special case” and throw an error if someone magically happens to try it.

Also it already accepts multiple expressions, expression.dependencies in DebugTag.ts is just a Set. Didn't have an issues with {@debug foo, bar} in testing.

I guess I'll have to just build the expression myself and then remove the dependencies after I use them in the build function. Just saw the tags init function which calls block.addDependencies. So simply removing the Tag extension should work.

[Rich-Harris]

this is great, thank you for working on this! I've created some tests in a separate branch — I wanted to make a PR against this branch but couldn't figure out how 😬 so feel free to just steal 'em

#1644

[Rich-Harris]

This doesn't quite work — the dependencies of an expression are the top-level data properties that it's ultimately derived from. So in this case...

{#each things as thing}
  {@debug thing}
{/each}

...the identifier is thing but the dependency is things.

[GarrettGeorge]

ahh I see, so the conditional is things.changed and then the ctx is thing?

[Rich-Harris]

we're missing the equivalent block (sans condition) for block.builders.create 😀

[GarrettGeorge]

• Add check to make sure expression type is SequenceExpression

Makes sure that {@debug a+b} is invalid

[Rich-Harris]

Thank you! I made a small tweak to the parser so that it handles single identifiers (i.e. {@debug foo}, which don't get returned as SequenceExpression nodes