Update dependency solid-js to v1.9.10

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
solid-js (source)	1.5.7 → 1.9.10

---

Release Notes

solidjs/solid (solid-js)

v1.9.10

Compare Source

v1.9.9

Compare Source

v1.9.8

Compare Source

v1.9.7

Compare Source

v1.9.6

Compare Source

v1.9.5

Compare Source

v1.9.4

Compare Source

v1.9.3

Compare Source

v1.9.2

v1.9.0: - LGTM!

Compare Source

This release like the last is focusing on small quality of life improvements and adjustments that will help us move towards 2.0. So while not the most exciting release to everyone it provides some really important features and fixes to some developers.

And unlike many previous releases the vast majority of the work and features came from PRs from the community. So really all I can say is Looks Good to Me!

Better JSX Validation

While still incomplete across templates we've added JSDOM to the compiler to better detect invalid HTML at build time by comparing what we expect the template to be with what a browser would output. This now includes things that are nested we didn't detect before like putting <a> inside other <a> tags which will lead to the browser "correcting" it in less than intuitive ways.

Improved Exports

While each environment in solid-js/web has its own methods to be used in the compiler. We are now exporting the client methods from the server to prevent weird import errors. Now these methods will throw if used in this environment but shouldn't break your build.

Additionally we have seen some issues in bundlers that incorrectly feed our ESM exports back through the browser field. While this is a known issue they all pointed issues at each other and with no intention of fixing it. We have removed the browser field in this release, meaning some legacy packages may have issues resolving browser if they don't support export conditions.

This is regretful but this blocked deployments on several platforms and since this was the only fix at our disposal after two years of attempting to push this issue to the bundlers to no avail, we've moved forward with it.

Custom Element improvements

We have a few improvements to our custom element support in this release. First off we now detect elements with the is attribute as custom elements which means all the special behavior is afforded to them.

We've also improved our event handler delegating retargetting to better handle shadow DOM events. There were cases where we skipped over part of the tree.

Finally we've added the bool: attribute namespace to handle explicitly setting certain attributes according to boolean attribute rules. While this isn't necessary for built-in booleans currently we handle most attributes as properties and we lacked a specific override. But now we have it:

<my-element bool:enable={isEnabled()}></my-element>

Support for handleEvent Syntax in Non-Delegated Events

A little known thing is that events actually also support objects instead of functions (See: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener)

We(thanks @​titoBouzout) realized we can use this mechanism as a way to set advanced rules like passive or capture on this object as way to handle all current and future event attributes that browsers might add. This way we don't need specific mechanisms like oncapture: (which is now deprecated).

Instead using on: you can set the event properties you wish.

<>
  <div on:click={{
    handleEvent(e) {
      console.log("clicked", e)
    },
    once:true
  }/>
  <div on:wheel={{
    handleEvent(e) {
      e.preventDefault() // only works on not passive events
      e.stopPropagation()  
      console.log("wheel stopped?")
    },
    passive: false
  }} />
</>

Other Updates

We've fixed an issue with lazy images. Apparently, cloneNode doesn't handle them properly so we've updated our heuristic to treat templates with lazy images to be handled with importNode.

We've improved our Hydration Mismatch Error to output the template of that it can't find the matching ID for. This should make it easier to track down where the hydration errors are occurring. There have been several hydration improvements over the later 1.8 releases so upgrading will likely improve the situation for those who have been facing issues.

Finally, we've improved some of the types in the JSX and Signal Setter in this release.

---

Big thanks to those who contributed to this release: @​wkelly17, @​olivercoad, @​titoBouzout, @​trusktr, @​Huliiiiii. And thanks to all of you who gave feedback on the Metadata/Head Tag RFC. While it didn't make it in this time around you've definitely given us stuff to consider for its future design.

Best,
@​ryansolid

v1.8.23

Compare Source

v1.8.22

Compare Source

v1.8.21

Compare Source

v1.8.20

Compare Source

v1.8.19

Compare Source

v1.8.18

Compare Source

v1.8.17

Compare Source

v1.8.16

Compare Source

v1.8.15

Compare Source

v1.8.14

Compare Source

v1.8.13

Compare Source

v1.8.12

Compare Source

v1.8.11

Compare Source

v1.8.10

Compare Source

v1.8.9

Compare Source

v1.8.8

Compare Source

v1.8.7

Compare Source

v1.8.6

Compare Source

v1.8.5

Compare Source

v1.8.4

Compare Source

v1.8.3

Compare Source

v1.8.2

Compare Source

v1.8.1

Compare Source

v1.8.0

Compare Source

I admit this is not the most exciting release from a feature standpoint. We are in that holding pattern between the end of 1.x and the start of 2.0. We recently made our new reactive experiments public and continue to build those out in public with @​solidjs/signals.

This version is more about addressing some of the fundamentals that will help us in other projects like SolidStart while we do the transition. A big part of this is applying what we have learned when doing performance benchmarks for the work that has been funded by Google Chrome Aurora.

Async and Resources need work and are too all in. It is great to have a solution but now that we have a better understanding we need to start breaking things apart into their fundamental pieces.

De-duping Streaming Serialization

This is the marquee feature of this release and is largely the work of @​lxsmnsyc. Solid has been able to serialize promises and do streaming for a couple of years now, but it was very special-cased. Now it is a generic mechanism.

This matters because it means that we have decoupled the promise serialization from Resources, and in so decoupled the whole when the stream is done from them. This opens up things like nested promises.

More so we have a mechanism now that deeply de-dupes data serialized across flushes. This is important for features like Islands where you might pass the same props to multiple Islands across different Suspense boundaries and don't want to send the data more than once. And even examples where that data can be accessed at varying depths (recursive comments in say a Hackernews site).

Hydration Improvements

Fragments for Hydration have been a bit of a pain and we keep seeming to have different issues reported around element duplication. Most commonly this has been around where there are lazy component siblings or where the fragment is top-level. After looking into and fixing an issue for Astro I decided to look at some of the oldest bugs in Solid and found it was a similar bug.

In many cases, the DOM can change throughout Hydration while doing things like streaming but we need to pause and resume hydration because code isn't available yet. While we don't create elements during hydration, getting an accurate snapshot of the DOM for the current state for future list reconciliation is a process we've had a few tries at but in 1.8 we update this in a way that makes sure it doesn't get out of date.

Also in 1.8, we have added some performance improvements to hydration in the form of not redundantly setting attributes or props as the page hydrates similar to how we don't update text. This is all migration towards a future where we don't need to do as much hydration, but it is important to note that values will be kept as they were on the server rather than how they may compute at runtime during hydration.

Smaller Templates

In 1.7 we removed unnecessary closing tags from template strings. It was a bit painful because we were a bit overzealous at first. While I believe in the end we got to a good place, ultimately all but the simplest reductions have been hidden behind a compiler flag(omitNestedClosingTags). Thanks to work from @​intrnl we are implementing another template size reduction technique of removing unnecessary quotes. Quotes are actually not required by HTML in some cases and it can add up.

Other

Fix NGINX Server Side Includes

Comments led with # are treated as special directives for a few different servers so we've needed to change our open hydration markers to $. As usual, your version of Solid and the Babel Plugin should be the same to ensure this matches up.

Better Guards on Global Scripts

Solid uses an inline HydrationScript as a way to do processing before the framework and code have loaded. To handle things like event capture and streaming. However, we didn't do a good job of guarding the right thing when multiple were added to the same page, a situation that can happen in Micro-frontends or 3rd party Islands solutions. Now the script guards against duplicate inclusion.

v1.7.12

Compare Source

v1.7.11

Compare Source

v1.7.10

Compare Source

v1.7.9

Compare Source

v1.7.8

Compare Source

v1.7.7

Compare Source

v1.7.6

Compare Source

v1.7.5

Compare Source

v1.7.4

Compare Source

v1.7.3

Compare Source

v1.7.2

Compare Source

v1.7.1

Compare Source

v1.7.0

Compare Source

Solid has experienced incredible growth in usage the last 6 months. Companies are using it to power production applications and SolidStart Beta has been a big part of that. As a natural part of this growth and increased use at scale we are continuing to learn what works well and what the rough edges in Solid are today.

This v1.7 release marks the beginning of the migration roadmap to v2.0. We are beginning to re-evaluate core APIs and will begin introducing new ones while reasonably deprecating older ones in a manner that eases breaking changes. Our intention is to ease the broader ecosystem into preparing for improvements that a major 2.0 will unlock for the whole community.

Improved TypeScript

Null-Asserted Control Flow

One of the pains of using Solid with TypeScript has been that JSX control flows can't really type narrow. This is true, but starting with the migration to explicit keyed in v1.5 we now complete this story by introducing callback forms for <Show> and <Match> that work when non-keyed.

The main difference is the callback form instead of passing in the value as it does when keyed, passes in a function that is type narrowed.

// keyed w/ callback - reruns full callback on change
<Show when={user()} keyed>
  {nonNullUser => <div>{nonNullUser.name}</div>}
</Show>

// non-keyed w/o callback... - only updates the one expression, needs ! assertion
<Show when={user()}>
  <div>{user()!.name}</div>
</Show>

// NEW!
// non-keyed w/ callback - only updates the one expression
<Show when={user()}>
  {nonNullUser => <div>{nonNullUser().name}</div>}
</Show>

Keep in mind because we are non-null asserting the input signal so it won't expect null in closures that execute when the condition is no longer satisfied. For this reason the accessor from the callback is special and will throw when attempted to be accessed when the condition is no longer true. This may be unexpected but it is our best attempt to keep TypeScript strict and not present inconsistency in reactivity. Luckily this only applies to things like timers which you should be cleaning up anyway and not things like event handlers. We recommend using the original conditions source in those closures if you must.

Better Event Types for Input Elements

This has irked people for a while but we come by it honestly, target is gives you a type of Element rather than the specific element that is the target. That means no access to .value or .checked. The reason is there is no way to know at compile time what the target of an event will be. The currentTarget will be the element you attach the event to but the target can be anything.

There is a way to work around this though, in that if we know the currentTarget is of type that generates the event and that the currentTarget is the the type of this element we can assume it is the target as well. Not perfect logic but it is what React does and we do too.

Now onInput, onChange, onBlur, onFocus, onFocusIn, and onFocusOut all support more detailed target when applied to HTMLInputElement, HTMLTextAreaElement, and HTMLSelectElement.

Stricter JSX Elements

Strict JSX elements have been tricky because we have to acknowledge at a certain point that TypeScript is to serve our purposes rather than to represent all possible values that could work. For us the ambiguity lies in functions.

Solid's JSX needs to accept functions to handle dynamic insertion. However, in authoring it leads to awkward situations.

The first you hit the first time use Solid. You create that counter and don't call count as a function and it works.

function Counter() {
  const [count, setCount] = createSignal(1);

  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

This example works in some places and not others which might lead to the wrong conclusions.

The second place you might hit this is when you get a little further on your journey and decide you need a component to re-render and decide that you can just wrap the whole thing in a function:

function MyComp(props) {
  return () => {
    // look working early returns
    if (props.count > 5) {
      return <div>Maximum Tries</div>;
    }

    return <div>Attempt {props.count}</div>;
  };
}

Again this seems fine, except the fact that every time count changes you are recreating all the DOM Elements even when it resolves to the same conditional.

Eventually you might even not think twice about passing functions into children of arbitrary components:

<MyComp>
  <MyComp2>
    <MyComp3>{() => <div>{resource()}</div>}</MyComp3>
  </MyComp2>
</MyComp>

But what does this do? When is the function called?

As it turns out removing functions from JSX.Element type makes all of these scenarios error. Components only expect the values dictated by their types.

function MyLayout(props: { children: JSX.Element }): JSX.Element;

function MyFor<T, U extends JSX.Element>(props: { each: T[],  children: (item: T) => U }): JSX.Element;

// valid
<MyLayout>Hello</MyLayout>
<MyLayout><p>Hello</p></MyLayout>
<MyLayout>{name()}</MyLayout>
<MyLayout>{name() && <p>Hello</p>}</MyLayout>
<MyLayout>{(() => {
  return <p{name()}</p>
})()}</MyLayout>
<MyLayout>{untrack(() => {
  return <p>{name()}</p>
})}</MyLayout>
<MyFor each={users()}>{(user) => <div>{user.name}</div>}</MyFor>

// invalid
<MyLayout>{name}</MyLayout>
<MyLayout>{() => <p>Hello</p>}</MyLayout>
<MyLayout>{() => "Hello"}</MyLayout>
<MyLayout>{() => name() && <p>Hello</p>}</MyLayout>
<MyFor each={users}>{(user) => <div>{user.name}</div>}</MyFor>
<MyFor each={users()}><div>Not a Function</div></MyFor>

The tradeoff here is that authoring components you can no longer just return a Signal or Memo without casting. If using JSX you can always return a Fragment.

If not you will need to cast to unknown as JSX.Element.

Better Errors and Cleanup

catchError replaces onError

Error Handling is complicated enough without having to try to guess how they propagate. onError admittedly is a lower level primitive but fundamentally had this flaw. It worked by registering an error handler on the parent scope, but left it ambiguous how to handle siblings. Is it a queue? Are they independent?

As a result we are introducing catchError in this release which introduces its own scope to catch any errors below it. The first argument in the primitive is similar to the try and the second argument is the catch.

catchError(
  () => {
    // do stuff
    throw new Error("I've Errored");
  },
  err => console.log(err)
);

onError will still be present until it can be removed in a future major version.

Standardized Errors

Error Handling has had many weird edge cases introduced by applications throwing unusual values. In v1.7 we wrap all thrown values that aren't of type Error in a new Error and attach the original thrown value as .cause.

More Performant Dev Tools

Now that Solid Dev Tools have been stabilizing, we have a much better idea what support we need for them. In so we were able to remove the very costly serialization we were doing for generating unique identifiers. Conventions around naming and exports were streamlined and standardized as well.

Others

• Smaller compiled output, remove auxilary closing tags
• Support for prop: and attr: in Spreads
• Don't apply special props (like readonly) to custom elements
• Introduced improved serializer, seroval
• Fixed quirks in Solid's treeshaking in Rollup
• Minify inline class and style attributes
• Update solid-ssr to type "module"

v1.6.16

Compare Source

v1.6.15

Compare Source

v1.6.14

Compare Source

v1.6.13

Compare Source

v1.6.12

Compare Source

v1.6.11

Compare Source

v1.6.10

Compare Source

v1.6.9

Compare Source

v1.6.8

Compare Source

v1.6.7

Compare Source

v1.6.6

Compare Source

v1.6.5

Compare Source

v1.6.4

Compare Source

v1.6.3

Compare Source

v1.6.2

Compare Source

v1.6.1

Compare Source

v1.6.0

Solid v1.6 doesn't bring a ton of new features but brings some big improvements in existing ones.

Highlights

Official Partial Hydration Support

Solid has worked for quite some time in partial hydrated ("Islands") frameworks like Astro, Iles, Solitude, etc.. but now we have added core features to support this effort better. These features are mostly designed for metaframework authors rather than the end user they are exposed through a couple APIs.

<Hydration /> joins <NoHydration /> as being a way to resume hydration and hydration ids during server rendering. Now we can stop and start hydratable sections. This is important because it opens up a new optimization.

createResource calls under non-hydrating sections do not serialize. That means that resources that are server only stay on the server. The intention is that hydrating Islands can then serialize their props coming in. Essentially only shipping the JSON for data actually used on the client.

The power here is static markup can interview dynamic components.

<h1>Server Rendered Header</h1>
<Island>
  <h2>Server Rendered Sub Header</h2>
  <p>{serverOnlyResource().text}</p>
  <DifferentIsland>
    <p>More server-renderd content</p>
  </DifferentIsland>
</Island>

Keep in mind Server rendered content like this can only be rendered on the server so to maintain a client navigation with this paradigm requires a special router that handles HTML partials.

Similarly we want the trees to talk to each other so hydrate calls now have been expanded to accept a parent Owner this will allow Islands to communicate through Contex without shipping the whole tree to browser.

<h1>Server Rendered Header</h1>
<ClientProvider>
  <h2>Server Rendered Sub Header</h2>
  <ClientIslandThatReadsContext />
</ClientProvider>

These improvements make it easier to create Partial Hydration solutions on top of Solid, and serve to improve the capabilities of the ones we already have.

Native Spread Improvements

Native spreads are something we started at very naively. Simply just iterating an object that has some reactive properties and updating the DOM element. However, this didn't take into consideration two problems.

First properties on objects can change, they can be added or removed, and more so the object itself can be swapped. Since Solid doesn't re-render it needs to keep a fixed reference to the merged properties. Secondly, these are merged. Properties override others. What this means is we need to consider the element holistically to know that the right things are applied.

For Components this was a never a problem since they are just function calls. Unfortunately for native elements this means all those compiler optimizations we do for specific bindings now need to get pulled into this. Which is why we avoided it in the past. But the behavior was too unpredictable.

In 1.6 we have smartened spread to merge properly using similar approach to how process Components. We've also found new ways to optimize the experience. (See below).

Other Improvements

Deproxification

Working on new Spread behavior we realized that while we can't tell from compilation which spreads can change. We can tell at runtime which are proxies. And in so if we only need to merge things which don't swap, and aren't proxies we can avoid making a Proxy.

What is great about this is it has a cascading effect. If component props aren't a proxy, then splitProps and mergeProps don't need to create them, and so on. While this requires a little extra code it is a real win.

We get a lot request for low end IoT devices because of Solid's incredible performance. In tests Solid outperforms many of the Virtual DOM solutions in this space. However most of them don't support proxies.

So now if you don't use a Store or swap out the props object:

// this is fine
<div {...props} />

// these could swap out the object so they make proxies
<div {...props.something} />
// or
<div {...someSignal()} />

We don't need to introduce any proxy the user didn't create. This makes Solid a viable option for these low-end devices.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.