fix(deps): update dependencies #73

renovate · 2021-07-24T00:15:50Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
atom-package-deps (source)	`^7.2.3` -> `^8.0.0`
solid-js (source)	`^0.26.5` -> `^1.0.0`

Release Notes

steelbrain/package-deps

`v8.0.0`

Compare Source

Potentially unstable: Minify the output to reduce size to ~10kb from ~30kb. (Thanks @aminya)

Although none of the APIs have changed, this change may be potentially unstable, so marking it as semver-major
so consumers have to opt-in to this.

solidjs/solid

`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.

`v1.5.6`

Compare Source

`v1.5.5`

Compare Source

`v1.5.4`

Compare Source

`v1.5.3`

Compare Source

`v1.5.2`

Compare Source

`v1.5.1`

Compare Source

`v1.5.0`

Compare Source

Key Highlights

New Batching Behavior

Solid 1.4 patched a long time hole in Solid's behavior. Until that point Stores did not obey batching. However, it shone a light on something that should maybe have been obvious before. Batching behavior which stays in the past is basically broken for mutable data, No Solid only has createMutable and produce but with these sort of primitives the sole purpose is that you perform a sequence of actions, and batching not making this properly was basically broken. Adding an element to an array then removing another item shouldn't just skip the first operation.

const store = createMutable(["a", "b", "c"]);

const move = store.splice(1, 1);
store.splice(0, 0, ...move);

// solid 1.4
// ["b", "a", "b", "c"];

// solid 1.5
// ["b", "a", "c"];

After a bunch of careful thought and auditting we decided that Solid's batch function should behave the same as how reactivity propagates in the system once a signal is set. As in we just add observers to a queue to run, but if we read from a derived value that is stale it will evaluate eagerly. In so signals will update immediately in a batch now and any derived value will be on read. The only purpose of it is to group writes that begin outside of the reactive system, like in event handlers.

More Powerful Resources

Resources continue to get improvements. A common pattern in Islands frameworks like Astro is to fetch the data from the out side and pass it in. In this case you wouldn't want Solid to do the fetching on initial render or the serialization, but you still may want to pass it to a resource so it updates on any change. For that to work reactivity needs to run in the browser. The whole thing has been awkward to wire up but no longer.

ssrLoadFrom field lets you specify where the value comes from during ssr. The default is server which fetches on the server and serializes it for client hydration. But initial will use the initialValue instead and not do any fetching or addtional serialization.

const [user] = createResource(fetchUser, {
  initialValue: globalThis.DATA.user,
  ssrLoadFrom: "initial"
});

We've improved TypeScript by adding a new state field which covers a more detailed view of the Resource state beyond loading and error. You can now check whether a Resource is "unresolved", "pending", "ready", "refreshing", or "error".

state	value resolved	loading	has error
unresolved	No	No	No
pending	No	Yes	No
ready	Yes	No	No
refreshing	Yes	Yes	No
errored	No	No	Yes

A widely requested feature has been allowing them to be stores. While higher level APIs are still being determined we now have a way to plugin the internal storage by passing something with the signature of a signal to the new Experimental storage option.

function createDeepSignal<T>(value: T): Signal<T> {
  const [store, setStore] = createStore({
    value
  });
  return [
    () => store.value,
    (v: T) => {
      const unwrapped = unwrap(store.value);
      typeof v === "function" && (v = v(unwrapped));
      setStore("value", reconcile(v));
      return store.value;
    }
  ] as Signal<T>;
}

const [resource] = createResource(fetcher, {
  storage: createDeepSignal
});

Consolidated SSR

This release marks the end of years long effort to merge async and streaming mechanism. Since pre 1.0 these were seperate. Solid's original SSR efforts used reactivity on the server with different compilation. It was easiest to migrate synchronous and streaming rendering and for a time async had a different compilation. We got them on the same compilation 2 years ago but runtimes were different. Piece by piece things have progressed until finally async is now just streaming if flushed at the end.

This means some things have improved across the board. Async triggered Error Boundaries previously were only ever client rendered (throwing an error across the network), but now if they happen any time before sending to the browser they are server rendered. onCleanup now runs on the server if a branch changes. Keep in mind this is for rendering effects (like setting a status code) and not true side effects as not all rendering cleans up.

Finally we've had a chance to do a bunch of SSR rendering performance improvements. Including replacing our data serializer with an early copy of Dylan Piercey from Marko's upcoming serializer for Marko 6. Which boasts performance improvements of up to 6x devalue which we used previously.

Keyed Control Flow

Solid's <Show> and <Match> control flow originally re-rendered based on value change rather than truthy-ness changing. This allowed the children to be "keyed" to the value but lead to over rendering in common cases. Pre 1.0 it was decided to make these only re-render when statement changed from true to false or vice versa, except for the callback form that was still keyed.

This worked pretty well except it was not obvious that a callback was keyed. So in 1.5 we are making this behavior explicit. If you want keyed you should specify it via attribute:

// re-render whenever user changes

// normal
<Show when={user()} keyed>
  <div>{user().name}</div>
</Show>

// callback
<Show when={user()} keyed>
  {user => <div>{user.name}</div>}
</Show>

However, to not be breaking if a callback is present we will assume it's keyed. We still recommend you start adding these attributes (and TS will fail without them).

In the future we will introduce a non-keyed callback form as well so users can benefit from type narrowing in that case as well.

Other Improvements

`children.toArray`

Children helper now has the ability to be coerced to an array:

const resolved = children(() => props.children);
resolved.toArray(); // definitely an array

Better SSR Spreads

Finally fixed spread merging with non-spread properties during SSR, including the ability to merge children.

Better Error Handling

We weren't handling falsey errors previously. Now when Solid receives an error that isn't an Error object or a string it will coerce it into an Unknown Error.

`v1.4.8`

Compare Source

`v1.4.7`

Compare Source

`v1.4.6`

Compare Source

`v1.4.5`

Compare Source

`v1.4.4`

Compare Source

`v1.4.3`

Compare Source

`v1.4.2`

Compare Source

`v1.4.1`

Compare Source

`v1.4.0`

Compare Source

New Features

Resource Deferred Streaming

Streaming brings a lot of performance benefits but it also comes with the tradeoff we need to respond with the headers before we can send any content. This means we must set the Response headers early if we want to benefit from streaming. While it's always possible to fetch first and delay rendering that slows down everything. Even our async server rendering doesn't block rendering but instead just waits to respond to the end.

But what if you want to stream but also want to wait on some key data loading so you still have an opportunity to handle the response on the server before sending it to the browser?

We now have the ability to tell Solid's stream renderer to wait for a resource before flushing the stream. That you can opt in by setting deferStream option.

// fetches a user and streams content as soon as possible
const [user] = createResource(() => params.id, fetchUser);

// fetches a user but only streams content after this resource has loaded
const [user] = createResource(() => params.id, fetchUser, { deferStream: true });

Top Level Arrays in Stores

Since Stores were first introduced it has always bugged me that the most common case, creating a list required nesting it under a property to track properly. Thanks to some exploration into proxy traps and iteration we now support top level arrays. In addition to its other modes, the Store setter will accept an array which allows for common operations.

const [todos, setTodos] = createStore([
  { id: 1, title: "Thing I have to do", done: false },
  { id: 2, title: "Learn a New Framework", done: false }
]);

// set at an index
setTodos(1, done, true);

// use an array
setTodos([...todos, { id: 3, title: "New Todo", done: false }])

// iterate over it with <For>
<For each={todos}>{todo => <Todo todo={todo} />}</For>;

Through this change we also stopped over execution when listening to specific properties. To support iteration Solid previously would notify the owning object of any array when an was index added/removed or object new property created or deleted on any object.

The one caveat is downstream optimized control flow that untrack index reads on arrays will now need to track the iterated object explicity. Solid exports a $TRACK symbol used to subscribe to the object and all its properties.

Stale Resource Reads

Suspense and Transitions are amazingly powerful feature but occasionally you want to opt out of the consistency and show things out of date because it will show up faster and some of things you are waiting for are not as high priority. In so you want the Transition to end sooner, but not necessarily stop showing the stale data for part of the screen. It is still preferable to receding back to loading spinner state.

Solid's Resources now support being able to read the value without triggering Suspense. As long as it has loaded previously latest property won't cause fallback appear or Transitions to hold. This will always return the latest value regardless whether it is stale (ie.. a new value is being fetched) and will reactively update. This is super powerful in Transitions as you can use the Resources own loading state to know if it is stale. Since the Transition will hold while the critical data is loading, the loading state will not be applied to the in view screen until that Transition has ended. If the resource is still loading now you can show that it is stale.

const [resource] = createResource(source, fetcher);

// read it as usual
resource();

// read the latest (don't suspend if loaded at least once)
resource.latest;

Example: https://codesandbox.io/s/solid-stale-resource-y3fy4l

Combining multiple Custom Renderers

The Babel plugin now allows configuring multiple custom renderers at the same time. The primary case it is so a developer can still lever Solid's optimized DOM compilation while using their custom renderer. To make this work specify the tags each renderer is reponsible for. It will try to resolve them in order.

import { HTMLElements, SVGElements } from "solid-js/web";
let solidConfig = {
  moduleName: "solid-js/web",
  // @&#8203;ts-ignore
  generate: "dynamic",
  renderers: [
    {
      name: "dom",
      moduleName: "solid-js/web",
      elements: [...HTMLElements, ...SVGElements]
    },
    {
      name: "universal",
      moduleName: "solid-three",
      elements: []
    }
  ]
};

Improvements/Fixes

Synchronous Top Level `createEffect`

These were originally deferred to a microtask to resemble how effects are queued under a listener. However it is more correct to run immediate like everything else top level.

Better Types around Components

This one took the effort of many resident TypeScript experts, but we've now landed on some better types for components. The biggest change is Component no longer has an opinion on whether it should have children or not. We've added supplementary types ParentComponent and FlowComponent to denote Components that may have children or always have children. And we've added VoidComponent for those which may never have children.

Sources in `createResource` are now Memos

A small change but it was unusual to have refetching trigger a reactive expression outside of a reactive context. Now on refetch it grabs the last source value rather than re-running it.

`createMutable` batches array methods like push, pop, etc..

Now these built-ins are batched and more performant. We've also add modifyMutable that applies modifiers batched to stores created with createMutable.

modifyMutable(state.data.user, reconcile({ firstName: "Jake", middleName: "R" }));

Stores and mutables now respect batch

Writing to a store or mutable within batch (including effects) no longer immediately updates the value, so reading within the same batch gives the old value. This guarantees consistency with memos and other computations, just like signals.

Better Support for React JSX transform

We have added support to solid-js/h to support the new React JSX transform. You can use it directly in TypeScript by using:

{
  "jsx": "react-jsx",
  "jsxImportSource": "solid-js/h"
}

Keep in mind this has all the consequences of not using the custom transform. It means larger library code, slower performance, and worse ergonomics. Remember to wrap your reactive expressions in functions.

HyperScript now returns functions

This one is a potentially breaking change, but the current behavior was broken. It was possible(and common) for children to be created before the parents the way JSX worked. This was an oversight on my original design that needs to be fixed, as it breaks context, and disposal logic. So now when you get your results back from h you need to call it. Solid's render function will handle this automatically.

const getDiv = h("div", "Hello");

document.body.appendChild(getDiv()); // call as a function to have it create the element.

Removals and Deprecations

`className`, `htmlFor` deprecated

While they still work for now, Solid will remove support for these React-isms in a future version. They leave us with multiple ways to set the same attribute. This is problematic for trying to merge them. Solid updates independently so it is too easy for these things to trample on each other. Also when optimizing for compilation since with things like Spreads you can't know if the property is present, Solid has to err on the side of caution. This means more code and less performance.

Experimental `refetchResources` removed

This primitive ended up being too general to be useful. There are enough cases we can't rely on the refetch everything by default mentality. For that reason we are dropping support of this experimental feature.

`v1.3.17`

Compare Source

`v1.3.16`

Compare Source

`v1.3.15`

Compare Source

`v1.3.14`

Compare Source

`v1.3.13`

Compare Source

`v1.3.12`

Compare Source

`v1.3.11`

Compare Source

`v1.3.10`

Compare Source

`v1.3.9`

Compare Source

`v1.3.8`

Compare Source

`v1.3.7`

Compare Source

`v1.3.6`

Compare Source

`v1.3.5`

Compare Source

`v1.3.4`

Compare Source

`v1.3.3`

Compare Source

`v1.3.2`

Compare Source

`v1.3.1`

Compare Source

`v1.3.0`

Compare Source

New Features

HTML Streaming

This release adds support for HTML streaming. Now we not only stream data after the initial shell but the HTML as it finishes. The big benefit is that now for cached results, or times when the network are slow we no longer have to show the placeholder while waiting for JavaScript bundle to load. As soon as the HTML is available it will be streamed and inserted.

With it comes new streaming API renderToStream. This is a universal API designed to handle both Node and Web writable streams. It returns an object that mirrors a Readable stream on both platforms that has both pipe (node) and pipeTo (web). The benefit of this pipe API is the user can choose when to insert the content in the output stream whether soon as possible, or onCompleteShell, or onCompleteAll. This decouples Solid's rendering a from the stream a bit but leaves things open to performance improvements in the future.

// node
const stream = renderToStream(() => <App />).pipe(res);

// web
const stream = renderToStream(() => <App />).pipeTo(writable);

Error Boundaries on the Server

We've added support for Error Boundaries on the Server for all rendering methods(renderToString, renderToStringAsync, renderToStream). Errors can be caught both from synchronous rendering and from errors that happen in Resource resolution. However, Our approach doesn't guarentee all errors are handled on the server as with streaming it is possible that the Error Boundary has already made it to the browser while a nested Suspense component hasn't settled. If an Error is hit it will propagate up to the top most Suspense Boundary that hasn't been flushed yet. If it is not handled by an Error Boundary before that it will abort rendering, and send the Error to the browser to propagate up to the nearest Error Boundary.

This works now but there is more to explore here in improving Error handling in general with SSR. So look forward to feedback on the feature.

Isolated Server Render/Hydration Contexts

Sometimes you want to server render and hydrate multiple Solid apps on the same page. Maybe you are using the Islands architecture with something like Astro. We now have the ability to pass a unique renderId on all our server rendering methods and to the hydrate function. This will isolate all hydration and resource resolution. This means we can use things like server side Suspense in these solutions.

Also now you only need to include the Hydration Script once on the page. Each Island will be responsible for initializing it's own resources.

// on the server
const html = renderToString(() => <Island1 />, { renderId: "island1" });

// for the browser
hydrate(() => <Island1 />, mountEl, { renderId: "island1" });

`createReaction`

This new primitive is mostly for more advanced use cases and is very helpful for interopt with purely pull based systems (like integrating with React's render cycle). It registers an untracked side effect and returns a tracking function. The tracking function is used to track code block, and the side effect is not fired until the first time any of the dependencies in the tracking code is updated. track must be called to track again.

const [s, set] = createSignal("start");

const track = createReaction(() => console.log("something"));

// next time s changes run the reaction
track(() => s());

set("end"); // "something"

set("final"); // no-op as reaction only runs on first update, need to call track again.

This primitive is niche for certain use cases but where it is useful it is indispensible (like the next feature which uses a similar API).

External Sources (experimental)

Ever wanted to use a third party reactive library directly in Solid, like MobX, Vue Reactivity, or Kairo. We are experimenting with adding native support so reactive atoms from these libraries can be used directly in Solid's primitives and JSX without a wrapper. This feature is still experimental since supporting Transitions and Concurrent Rendering will take some more effort. But we have added enableExternalSource enable this feature. Thanks @3Shain for designing this solution.

import { Reaction, makeAutoObservable } from "mobx";
import { enableExternalSource } from "solid-js";
import { render } from "solid-js/web";

let id = 0;
enableExternalSource((fn, trigger) => {
  const reaction = new Reaction(`externalSource@${++id}`, trigger);
  return {
    track: x => {
      let next;
      reaction.track(() => (next = fn(x)));
      return next;
    },
    dispose: () => {
      reaction.dispose();
    }
  };
});

class Timer {
  secondsPassed = 0;

  constructor() {
    makeAutoObservable(this);
  }

  increase() {
    this.secondsPassed += 1;
  }

  reset() {
    this.secondsPassed = 0;
  }
}

// component driven directly off MobX
function App() {
  const timer = new Timer();
  setInterval(() => {
    timer.increase();
  }, 1000);

  return <button onClick={() => timer.reset()}>Seconds passed: {timer.secondsPassed}</button>;
}

render(() => <App />, document.getElementById("app"));

`refetchResources` (experimental)

In efforts to allow for scaling from simple resources up to cached solutions we are adding some experimental features to createResource to work with library writers to develop the best patterns. Caching is always a tricky problem and with SSR and streaming being part of the equation the core framework needs at minimum to provide some hooks into orchestrating them.

Sometimes it's valuable to trigger refetch across many resources. Now you can.

import { createResource, refetchResources } from "solid-js";

const userCache = {};

function MyComponent(props) {
  const [data] = createResource(
    () => props.id,
    (userId, { refetching }) => {
      const cached = userCache[userId];

      // return cached value if available and not refetching
      if (cached && !refetching) return cached;
      return fetchUser(userId);
    }
  );
}

// somewhere else
refetchResources();

You can also pass a parameter to refetchResources to provide additional information to the refetching info of the fetcher. This could be used for conditional cache invalidation. Like only refetch resources related to users. This mechanism requires a bit of wiring but the idea is you'd wrap createResource in maybe a createQuery and implement your own conventions around resource cache management. Still working out how this should work best, but the goal is to provide the mechanisms to support resource caches without being responsible for their implementation.

To opt-out being part of the global refetch createResource now takes a globalRefetch option that can be set to false. In addition to a new option to disable refetchResources there is no an onHydrated callback that takes the same arguments as the fetcher. When a resource is restored from the server the fetcher is not called. However, this callback will be. This is useful for populating caches.

Improvements

Better TypeScript Support

Thanks to the tireless efforts of several contributors we now have significantly better types in Solid. This was a huge effort and involved pulling in maintainers of TypeScript to help us work through it. Thank you @trusktr for spearheading the effort.

Better SourceMaps

Work has been done to improve sourcemaps by updating babel-plugin-dom-expressions to better preserve identifiers from the JSX. Thanks to @LXSMNSYC for exploring and implementing this.

Breaking Changes/Deprecations

`startTransition` no longer takes callback as a second argument

Instead it returns a promise you can await. This works better for chaining sequences of actions.

const [start, isPending] = useTransition();

start(() => doSomething()).then(() => allDone());

Resource fetcher info object replaces `getPrev`

To streamline API for refetch we are slightly updating the createResource:

const [data] = createResource(sourceSignal, (source, { value, refetching }) => {});

For those using existing 2nd argument:

const [data] = createResource(sourceSignal, (source, getPrev) => {
  const value = getPrev();
});

// becomes
const [data] = createResource(sourceSignal, (source, { value }) => {});

Deprecating Legacy Streaming APIs

pipeToNodeWritable and pipeToWritable are deprecated. They will still work for now with basic usage but some of the more advanced options didn't map over to the new APIs directly and have been removed. Move to using renderToStream.

Bug Fixes

Fixed browser extensions modifying the head breaking hydration.
Fixed reinserting <html> on hydration from document.
Fixed over-executing on multi-select with createSelector.
Fixed event delegation conflicting with document event listeners.
Fixed self owning source infinite recursion.
Fixed faulty treesplitting for hydration in client only render.
Fixed return type of preload on lazy components to always be a promise.
Fixed compile error with leading white space after opening tags when generating ssr.

`v1.2.6`

Compare Source

`v1.2.5`

Compare Source

`v1.2.4`

Compare Source

`v1.2.3`

Compare Source

`v1.2.2`

Compare Source

`v1.2.1`

Compare Source

`v1.2.0`

Compare Source

New Features

Custom Renderers

This release adds support custom renderers through a new "universal" transform. Solid now provides a sub module solid-js/universal that exports a createRenderer method that allows you to create your own runtimes. This will enable things like native mobile and desktop, canvas and webgl, or even rendering to the terminal. This is still new so very much looking for feedback.

Spreads Added to Solid's `html`

It's been a long time coming but Solid's Tagged Template Literals now support element and component spreads using htm inspired syntax.

html`<div ...${props} />`;

Fixes

Dynamic Spreads now work on Components

Previously spreads on components would only track property changes on bound objects and not when the whole object changed. This now works:

<MyComponent {...getStuff()} />

ClassList properly merges multiple classnames in the key

It is common in libraries like Tailwind to apply multiple classes at the same time. There was an issue where true and false resolutions were cancelling each other out. This would only set text-sm.

<div
  classList={{
    "px-2.5 py-1.5 text-xs": false,
    "px-3 py-2 text-sm": false,
    "px-4 py-2 text-sm": true,
    "px-4 py-2 text-base": false,
    "px-6 py-3 text-base": false
  }}
/>

Consistent handling of HTMLEntities

Things like   used to render differently depending if in elements or components(or fragments). This has been made consistent across all three.

Various improvements to Types and Transitions

A lot of bugs from the last minor release were around Transitions that have been addressed. And as always Types have been gradually improving.

`v1.1.7`

Compare Source

`v1.1.6`

Compare Source

`v1.1.5`

Compare Source

`v1.1.4`

Compare Source

`v1.1.3`

Compare Source

`v1.1.2`

Compare Source

`v1.1.1`

Compare Source

`v1.1.0`

Compare Source

Expanding Solid's concurrency to include scheduling. Bug fixes around Types and around reactive execution order guarantees.

New Features

`createUniqueId`

A universal id generator that works across server/browser.

const id = createUniqueId();

Note on the server this only works under hydratable components

`from`

A simple helper to make it easier to interopt with external producers like RxJS observables or with Svelte Stores. This basically turns any subscribable (object with a subscribe method) into a Signal and manages subscription and disposal.

const signal = from(obsv$);

It can also take a custom producer function where the function is passed a setter function returns a unsubscribe function:

const clock = from(set => {
  const t = setInterval(() => set(1), 1000);
  return () => clearInterval(t);
});

Note: Signals created by from have equality checks turned off to interface better with external streams and sources.

`enableScheduling` (experimental)

By default Solid's concurrent rendering/Transitions doesn't schedule work differently and just runs synchronously. Its purpose is to smooth out IO situations like Navigation. However now you can opt into interruptible scheduling similar to React's behavior by calling this once at your programs entry. I've yet to see a realworld scenario where this makes a big difference but now we can do cool demos too and start testing it.

`startTransition`

Works like its counterpart in useTransition, this useful when you don't need pending state.

import { createSignal, startTransition } from "solid-js";

function App() {
  const [signal, setSignal] = createSignal("Howdy");
  function clickHandler(e) {
    startTransition(() => setSignal("Holla"));
  }

  /* ...stuff */
}

`v1.0.7`

Compare Source

`v1.0.6`

Compare Source

`v1.0.5`

Compare Source

`v1.0.4`

Compare Source

`v1.0.3`

Compare Source

`v1.0.2`

Compare Source

`v1.0.1`

Compare Source

`v1.0.0`

Compare Source

Breaking Changes

setSignal now supports function form

While that in itself is a great new feature as you can do:

const [count, setCount] = createSignal(0);

setCount(c => c + 1);

This promotes immutable patterns, let's you access the previous value without it being tracked, and makes Signals consistent with State.

It means that when functions are stored in signals you need to use this form to remove ambiguity

const [count, setCount] = createSignal(ComponentA);

// Do this:
setCount(() => ComponentB);

// Don't do this as it will call the function immediately:
setCount(ComponentB);

`createState` moved and renamed

createState has been renamed to createStore and moved to solid-js/store. Also moved to solid-js/store: createMutable, produce, reconcile

SSR Entry points

renderToString and renderToStringAsync now only return their stringified markup. To insert scripts you need to call generateHydrationScript or use the new <HydrationScript> component.

renderToNodeStream and renderToWebStream have been replaced with pipeToNodeWritable and pipeToWritable, respectively.

Options Objects

Most non-essential arguments on reactive primitives are now living on an options object. This was done to homogenize the API and make it easier to make future additions while remaining backwards compatible.

on

No longer uses rest parameters for multiple dependencies. Instead pass an array. This facilitates new option to defer execution until dependencies change.

Actions renamed to Directives

To remove future confusion with other uses of actions the JSX.Actions interace is now the JSX.Directives interface.

Configuration

📅 Schedule: Branch creation - "every weekend" (UTC), 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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

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

This PR has been generated by Mend Renovate. View repository job log here.

renovate · 2023-03-22T17:50:03Z

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠ Warning: custom changes will be lost.

renovate bot added the dependencies Pull requests that update a dependency file label Jul 24, 2021

fix(deps): update dependencies

aecd54a

renovate bot force-pushed the renovate/dependencies branch from e53138a to aecd54a Compare July 24, 2021 01:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(deps): update dependencies #73

fix(deps): update dependencies #73

renovate bot commented Jul 24, 2021 •

edited

Loading

renovate bot commented Mar 22, 2023

fix(deps): update dependencies #73

Are you sure you want to change the base?

fix(deps): update dependencies #73

Conversation

renovate bot commented Jul 24, 2021 • edited Loading

Release Notes

Highlights

Official Partial Hydration Support

Native Spread Improvements

Other Improvements

Deproxification

Key Highlights

New Batching Behavior

More Powerful Resources

Consolidated SSR

Keyed Control Flow

Other Improvements

children.toArray

Better SSR Spreads

Better Error Handling

New Features

Resource Deferred Streaming

Top Level Arrays in Stores

Stale Resource Reads

Combining multiple Custom Renderers

Improvements/Fixes

Synchronous Top Level createEffect

Better Types around Components

Sources in createResource are now Memos

createMutable batches array methods like push, pop, etc..

Stores and mutables now respect batch

Better Support for React JSX transform

HyperScript now returns functions

Removals and Deprecations

className, htmlFor deprecated

Experimental refetchResources removed

New Features

HTML Streaming

Error Boundaries on the Server

Isolated Server Render/Hydration Contexts

createReaction

External Sources (experimental)

refetchResources (experimental)

Improvements

Better TypeScript Support

Better SourceMaps

Breaking Changes/Deprecations

startTransition no longer takes callback as a second argument

Resource fetcher info object replaces getPrev

Deprecating Legacy Streaming APIs

Bug Fixes

New Features

Custom Renderers

Spreads Added to Solid's html

Fixes

Dynamic Spreads now work on Components

ClassList properly merges multiple classnames in the key

Consistent handling of HTMLEntities

Various improvements to Types and Transitions

New Features

createUniqueId

from

enableScheduling (experimental)

startTransition

Breaking Changes

setSignal now supports function form

createState moved and renamed

SSR Entry points

Options Objects

on

Actions renamed to Directives

Configuration

renovate bot commented Jul 24, 2021 •

edited

Loading

`children.toArray`

Synchronous Top Level `createEffect`

Sources in `createResource` are now Memos

`createMutable` batches array methods like push, pop, etc..

`className`, `htmlFor` deprecated

Experimental `refetchResources` removed

`createReaction`

`refetchResources` (experimental)

`startTransition` no longer takes callback as a second argument

Resource fetcher info object replaces `getPrev`

Spreads Added to Solid's `html`

`createUniqueId`

`from`

`enableScheduling` (experimental)

`startTransition`

`createState` moved and renamed