Minified / cleanup up the svg files

In https://github.com/sveltejs/svelte/issues/6373#issuecomment-863801628, an idea using labels came to me.

<script lang=ts>
import { value$ } from './value$'
export value = $value$
value: $value$
</script>

<input bind:value>

Where the reactive variable value is a proxy for the reactive store value $value$. On the surface, it seems like the label proxy is a different use case (being in the <script>), but it seems like a use case which could be a factor in the design of contextual store proxies.

SVGO has a hella ton of settings—is there a config you're after? Or just default out of the box settings?

Some of these SVGs are not minified - can you run all of them through svgo?

Are you seeing something different?

I was, but I think it was an order of execution thing: Svelte seems to bind props after the contents of a component's <script> tag runs, and so my testing approach was flawed. I can reproduce the expected behavior that you described, thanks.

Environment

• Elixir & Erlang/OTP versions (elixir --version):

Erlang/OTP 24 [erts-12.0.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.12.1 (compiled with Erlang/OTP 22)

• Operating system: macOS Big Sur 11.2.3

Current behavior

iex(1)> String.to_existing_atom("valid_utf8")
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: invalid UTF8 encoding

    :erlang.binary_to_existing_atom("valid_utf8", :utf8)

The error is a lie. It's valid UTF-8, it just doesn't exist as an atom.

Expected behavior

It would be great if it could tell us the atom doesn't exist. If that's not possible though, we should at least stop giving an incorrect reason.

Precisely, thanks @thiamsantos and @JEG2!

I think it is the same error reported at https://github.com/elixir-lang/elixir/issues/11014. It seems to be already fixed in OTP https://github.com/erlang/otp/commit/c1942e39d44d50bb4bdf8e22456f31ee23931fdb.

Environment

• Elixir & Erlang/OTP versions (elixir --version):

Erlang/OTP 24 [erts-12.0.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.12.1 (compiled with Erlang/OTP 22)

• Operating system: macOS Big Sur 11.2.3

Current behavior

iex(1)> String.to_existing_atom("valid_utf8")
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: invalid UTF8 encoding

    :erlang.binary_to_existing_atom("valid_utf8", :utf8)

The error is a lie. It's valid UTF-8, it just doesn't exist as an atom.

Expected behavior

It would be great if it could tell us the atom doesn't exist. If that's not possible though, we should at least stop giving an incorrect reason.

Svelte won't reflect property changes to the corresponding attribute automatically. You have to do that yourself, which is a little tricky since there isn't a defined way to get the current custom element instance (see #3091). You can work around it using the get_current_component internal API, but this could change behavior without warning because it's not intended for external use.

Here's an example of updating the element's name attribute when the property changes. Clicking the button will set the <my-el> name property to true as well as the attribute.

<script>
	export let name;

	import { get_current_component } from 'svelte/internal';

	$: get_current_component().setAttribute('name', name);
</script>

<svelte:options tag="my-el"></svelte:options>

<p>Hello {name}</p>
<button on:click={() => name = 'test'}>Update name</button>

This would be a nice feature to have built in for those authoring custom elements in Svelte. Other frameworks like Lit make it easy.

I see this more generally: any change to a prop of a web component (e.g., adding value = 'foo'; at the bottom of your script) does not propagate to the component, either as a property or an attribute.

@richnew10 I do see the property being updated on the custom element in my example, i.e. document.querySelector('my-el').name returns test after clicking the button. Are you seeing something different?

I think we can detect and raise on duplicate keys. I can see how using list and thus preserving order can be useful for reflection purposes but no strong opinion either way.

Well I think it's pretty hard to trigger such thing. The symptom isn't too harmful - just potentially calling the go function redundantly, because it has been already called. I don't think there's a reason to delete this function since it can hurt transition's internal functionalities, which seems pretty fine.

ついでに付録のディレクトリを chap から appendix にリネームしています。

Would map be a more reasonable data structure here? Because keyword would let you do something like this: [foo: "foo", foo: "fooo"] and the first one would win.

Hi @richnew10, No, I haven't looked further into this. We ended up just using the property names instead of attributes since it's consistent and we don't get the out-of-sync problem.

In the mean time, before the PR is accepted, you can use the {@html} function with JS template strings to get the desired result.

App.svelte

<script>
    import Header from "./Header.svelte";
</script>

<main>
    <Header headerType="h1" />
</main>

Header.svelte

<script>
    export let headerType;
</script>

{@html `<${headerType}>Hello, World!</${headerType}>`}

View on the Svelte REPL here.

Another workaround => REPL: https://svelte.dev/repl/8dcde41369cf440da948b65bc069322b?version=3.38.2

Although technically spec compliant, URI.decode_www_form fails to convert a %% to a %. We do receive URLs which contain %% instead of %25 from sources which we do not control.

Upon receiving a %% eg curl 'http://localhost:4000/bla?value=%%' we get an error:

** (Plug.Conn.InvalidQueryError) invalid urlencoded params, got %%

Environment

• Elixir & Erlang/OTP versions (elixir --version): 1.12.1
• Phoenix: 1.5.9
• Operating system: Mac os 11.3

Current behavior

iex(13)> URI.decode_www_form "http://localhost:4000/bla?value=%%"
** (ArgumentError) malformed URI "http://localhost:4000/bla?value=%%"
    (elixir 1.12.1) lib/uri.ex:440: URI.decode_www_form/1
iex(14)> URI.decode_www_form "http://localhost:4000/bla?value=%25"
"http://localhost:4000/pixel?value=%"

Expected behavior

It would be nice to have the following behaviour

iex(13)> URI.decode_www_form "http://localhost:4000/bla?value=%%"
"http://localhost:4000/pixel?value=%"
iex(14)> URI.decode_www_form "http://localhost:4000/bla?value=%25"
"http://localhost:4000/pixel?value=%"

Thank you for the discussion. I have some good news to report. I have been rolling out the val$ naming convention & all of the naming conflicts around stores has been resolved, particularly in *.ts files. My projects tend to have the majority of the logic in stores & less logic in templates. I have also broken out Controller classes for logic-heavy templates, which includes functions, writable & derived stores. The naming conflicts resolved include:

• Before: should a $ prefix be applied to local variables? After: the value variable name has no $ character
• Before: props: should a $ prefix be used on the prop name? After: The prop name has no $ character
• Before: In preload, the $ prefix cannot be used for local variables due to the Svelte Compiler. After: No $ prefix necessary to distinguish between store & value.

The $val$ component values are also not too bad to work with either. It conceptually makes sense in a certain way, as the $ prefix & suffix cancel each other out, like a + & -? cancel each other out in arithmetic. It is an extra character, but one could make the aesthetic argument that$val$is balanced. The$prefix can be thought of as a preprocessor operator on thestore$object. This means it seems ok to not have to change the syntax, as long as$prefix & suffix ($val$`) is not too much of an eyesore & burden for the programmer. I'm not opposed to changing the syntax either, but having gone through 2 migrations, I can see that it would be a sizable effort for large codebases. Less than 1 week in most cases, but still sizable.

https://twitter.com/wycats/status/1380386140478271488

Yehuda Katz had an interesting insight into composing reactive cell primitives (i.e. svelte stores). I'm looking for ways to ergonomically compose svelte stores into objects as well. I have started to add the _ get/set prop on the stores that I use.

const val$ = writable('')
val$._ = 'new value`
console.info(val$._)

It would be interesting to compose svelte stores into objects. For my purposes, mainly in Controller logic, having a store directly set as a prop works great. There's no need for decorators & reading/writing values from stores can occur inline.

Ah hadn’t thought of that, thanks that’s a great idea

On 18/06/2021, at 4:57 PM, José Valim ***@***.***> wrote:

Yes, according to the spec you are correct: https://url.spec.whatwg.org/#percent-decode

we should append % if it is not followed by digits.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart: