{
  "id": "1667c3ec4c8cf00f2c593623",
  "source": "solid:signals",
  "type": "github-document",
  "title": "migration",
  "content": "---\ntitle: Migration from v0.9.x\nuse_cases: \u003e-\n  upgrading from v0.9, breaking changes, api migration, updating legacy code,\n  version upgrade\ntags:\n  - migration\n  - upgrade\n  - breaking-changes\n  - v0.10\n  - api-changes\n  - legacy\nversion: '1.0'\ndescription: \u003e-\n  Migrate your Solid Router application to v0.10 with this comprehensive guide\n  covering removed APIs, new patterns, and Islands support changes.\n---\n\nv0.10.0 brings some big changes to support the future of routing including Islands/Partial Hydration hybrid solutions.\nMost notably there is no Context API available in non-hydrating parts of the application.\n\nThe biggest changes are around _removed APIs_ that need to be replaced.\n\n## `\u003cOutlet\u003e`, `\u003cRoutes\u003e`, `useRoutes`\n\nThese components are no longer present in the new router version. Instead, `props.children` is passed into the page components in the place of outlets.\nThis keeps the outlet directly passed from its page and avoids trying to use context across Islands boundaries.\nSimilarly, nested `\u003cRoutes\u003e` components cause waterfalls and are `\u003cOutlets\u003e` themselves thus sharing the same concerns.\n\nWith no `\u003cRoutes\u003e` means the `\u003cRouter\u003e` API has changed.\nThe `\u003cRouter\u003e` component acts as the `\u003cRoutes\u003e` component now and its children must now be `\u003cRoute\u003e` components.\nThe top-level layout should go in the root prop of the router [as shown here](/solid-router/concepts/layouts#root-level-layouts).\n\n## `element` prop removed from `Route`\n\nRelated without Outlet component it has to be passed in manually.\nAt which point the `element` prop has less value.\nRemoving the second way to define route components to reduce confusion and edge cases.\n\n## `data` functions \u0026 `useRouteData`\n\n`data` functions \u0026 `useRouteData` have been replaced by a load mechanism.\nThis allows link hover preloads, since the preload function can be run as much as wanted without worrying about reactivity.\n\nThis supports deduping/cache APIs which give more control over how things are cached.\nIt also addresses TypeScript issues with getting the right types in the Component without `typeof` checks.\n\nThat being said the old pattern can be reproduced by turning off preloads at the router level and then injecting your own Context:\n\n```js\nimport { lazy } from \"solid-js\";\nimport { Router, Route } from \"@solidjs/router\";\n\nconst User = lazy(() =\u003e import(\"./pages/users/[id].js\"));\n\n// preload function\nfunction preloadUser({ params, location }) {\n\tconst [user] = createResource(() =\u003e params.id, fetchUser);\n\treturn user;\n}\n\n// Pass it in the route definition\n\u003cRouter preload={false}\u003e\n\t\u003cRoute path=\"/users/:id\" component={User} preload={preloadUser} /\u003e\n\u003c/Router\u003e;\n```\n\nAnd then in your component taking the page props and putting them in a Context.\n\n```js\nimport { createContext, useContext } from \"solid-js\";\n\nconst UserContext = createContext();\n\nfunction User(props) {\n\t\u003cUserContext.Provider value={props.data()}\u003e\n\t\t{/* my component content that includes \u003cUserDetails /\u003e in any depth  */}\n\t\u003c/UserContext.Provider\u003e;\n}\n\nfunction UserDetails() {\n\tconst user = useContext(UserContext);\n\t// render stuff\n}\n```",
  "url": "https://github.com/solidjs/solid-docs/blob/HEAD/src/routes/solid-router/guides/migration.mdx",
  "metadata": {
    "path": "src/routes/solid-router/guides/migration.mdx",
    "repo": "solidjs/solid-docs",
    "repo_url": "https://github.com/solidjs/solid-docs.git",
    "size": 3105,
    "source_type": "github"
  },
  "hash": "28176e2c18c401dbceb2edb07fb13d05c5f4275bec1030833d428284ce823fd5",
  "timestamp": "2026-02-23T11:43:00.192262846+01:00"
}