For example, TikTok has upgraded to React 18 already (twitter.com/Brooooook_lyn/status/1402632529270632456?s=20)

This looks like they're just testing integration, not pushing React 18 to production.

I personally don't see any issue with app devs trying the alpha already. From how I understood it, this isn't generally recommended because most apps use at least one library. So it might be frustrating if you want to try it out, but upstream isn't ready. So right now the goal is to work the problem bottom up so that library maintainers aren't flooded with issues regarding "React 18 compat when?". But that's just from my perspective.

Rather than listing libraries that aren't ready (putting negative pressure on those maintaienrs) we may want to start a list of the libraries that are compatible. Though right now is probably too early.

can reduce other one's time-wasting.

I think there's a mismatch of expectations here. Upgrading to React 18 right now is most likely not the most productive task. Upgrading and facing issues right now should be the expecation so considering it a "waste of time" isn't very constructive. The React working group is actively looking for such issues right now. Idenitfiying these issues is the exact opposite of "wasting time".

It's not 100% clear to me what "purely advisory" means. The processing model only defines this for theme-color, and it seems like it'd be better to explicitly say that this does nothing for other meta names. (viewport seems a case that would be particularly concerning if someone decided to be creative and add support)

Looks like we have 2 LGTMs then, but @ljharb's wasn't properly registered since it's a comment.

And here's our intent to prototype and ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/6I-I3lZWy5k

Closes #1999

✅ Pull Request Checklist:

• [X] Included link to corresponding React Spectrum GitHub Issue.
• [ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• [ ] Filled out test instructions.
• [ ] Updated documentation (if it already exists for this component).
• [ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

<!--- Include instructions to test this pull request -->

🧢 Your Project:

Adobe/RSP

I think this newer text indeed better reflects what we should be saying here, and also highlights the tradeoffs.

When I copy this:

https://codesandbox.io/s/github/reduxjs/redux-toolkit/tree/example/graphql-codegen/examples/query/react/graphql-codegen?file=/src/app/services/graphqlRequestBaseQuery.ts

to my api file it works.

@isiahmeadows thanks. If you can confirm the polyfill reflects your proposal, I might publish it already under @ungap + I don't see it problematic or much slower than what insertBefore could be already. I'll try to reach out Dmitry too for thoughts around breaking changes.

Hmm, I think I see. Can you try to import the graphqlRequestBaseQuery directly from the sources instead of the built package?

@WebReflection That is correct. The idea is that you're inserting a node, but specifically after nothing. And if nothing's supposed to be before it, then you're essentially prepending it. And so yes, that's the intent.

• elem.insertAfter(node, null) → elem.prepend(node)
• elem.insertAfter(node, refNode) → refNode.after(node)
• elem.insertAfter(node, elem.lastChild) → elem.append(node)

I am using standard api:

const api = createApi({
  baseQuery: graphqlRequestBaseQuery({
    url: '/graphql',
  }),
  endpoints: () => ({}),
});

standard store:

const store = configureStore({
  reducer: {
    map: mapReducer,
    deviceDetails: deviceDetailsReducer,
    [api.reducerPath]: api.reducer,
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(api.middleware),
});

Classic redux implementation:

 <ReduxProvider store={store}>
      <NextAuthProvider session={pageProps.session}>
        <Component {...pageProps} />
      </NextAuthProvider>
 </ReduxProvider>

Also I am using graphql-codegen plugin for rtk-query, by @phryneas.

Here is generated endpoint:

import * as Types from '../../../graphql/generated/client/typegen';

import { api } from 'src/services/api';
export type CreateDeviceMutationVariables = Types.Exact<{
  allow: Types.Scalars['Int'];
  access: Types.Scalars['Int'];
  name: Types.Scalars['String'];
  metadata?: Types.Maybe<Types.Scalars['Json']>;
  elevation?: Types.Maybe<Types.Scalars['Int']>;
  latitude: Types.Scalars['Float'];
  longitude: Types.Scalars['Float'];
  desciption?: Types.Maybe<Types.Scalars['String']>;
}>;

export type CreateDeviceMutation = { __typename?: 'Mutation' } & Pick<
  Types.Mutation,
  'createDevice'
>;

export const CreateDeviceDocument = `
    mutation createDevice($allow: Int!, $access: Int!, $name: String!, $metadata: Json, $elevation: Int, $latitude: Float!, $longitude: Float!, $desciption: String) {
  createDevice(
    input: {name: $name, allow: $allow, access: $access, latitude: $latitude, metadata: $metadata, elevation: $elevation, longitude: $longitude, description: $desciption}
  )
}
`;

const injectedRtkApi = api.injectEndpoints({
  endpoints: (build) => ({
    createDevice: build.mutation<
      CreateDeviceMutation,
      CreateDeviceMutationVariables
    >({
      query: (variables) => ({ document: CreateDeviceDocument, variables }),
    }),
  }),
});

export { injectedRtkApi as api };
export const { useCreateDeviceMutation } = injectedRtkApi;

Here is error video: https://webmshare.com/play/BeOB4

If I comment out reducer from store app works again.

@isiahmeadows so ... considering this previous scenario:

list.insertAfter(task, null)

would produce:

<ul id="list">
  <li>last task</li>
  <li>first task</li>
  <!-- some comment -->
</ul>

I understand the specular API idea behind, but I find it a bit counter-intuitive ... anyway, not opposing, or anything, just wantet to understand the rationale or use case. I don't use vDOM, but I do use DOM diffing, so these methods might be handy for my use cases too.

Are there benchmarks for this? @smaug---- @rniwa thoughts?

@annevk As for the cost of C++, consider this diff. We got serious gains from two things:

1. Avoiding a polymorphic property lookup by performing a polymorphic type check on the value first (counterintuitive, but it made a noticeable difference).
2. Avoiding a long series of unnecessary calls to C++ land and reducing it to a dictionary property update.

And that's for a reasonably simple pair of algorithms. (The date of that diff should give you an idea how long ago I last ran those benchmarks, but I've watched the situation on JS perf, and little has changed in this area - I can tell you that for certain.)

Note that HTTP provides no guarantee that chunks are preserved end-to-end; furthermore, many (most?) HTTP APIs don't guarantee that chunk delineation is exposed accurately.

@webreflection Had to recast my comment because I misinterpreted your response. Please see my updated comment. 🤦‍♀️

With fetchBaseQuery it works flawless:

const api = createApi({
  baseQuery: fetchBaseQuery({
    baseUrl,
  }),
  endpoints: () => ({}),
});

If child is null, this prepends node as the first child.

with insertBefore, if child is null the element is appended (like appendChild would do) ... I find this proposed behavior here a bit controversial ... the before "appends with null, the after "prepend" with null as first child ... am I the only one not fully getting the use case for prepending as first child with a method called after ?

@WebReflection It's based on the semantics of elem.insertBefore

• elem.insertBefore(node, null) appends because in essence, it's just seeking forward from the start to the position within the element's children right before the reference node (without skipping past it) and inserting there. Absent a reference node, it just seeks to the end (where it can't seek further), thus appending.
• elem.insertAfter(node, null) I'm proposing to prepend because of the same reason, just in the opposite direction and starting from the opposite end. It seeks back from the start to the position within the element's children right after the reference node (as in, it likewise doesn't skip past it) and inserting the node there. Absent a reference node, it just seeks to the start (where it can't seek further), thus prepending.

Of course, it's not spec'd like this (nobody with any sense is going to implement it that way), but that's the general idea.

Separately, in virtual DOM frameworks, in the face of fragments, we literally don't know what the next sibling will be, and so it's faster for us to recompute it each time from our internal model.

There's a chance, otherwise this would be closed. It does however require folks to be willing to implement it and drive the associated work that is required and that thus far has not materialized.

Related URL

• https://smarthr.atlassian.net/browse/SHRUI-265

Overview

• Footer needed own attributes improved.
• Footer component needed default class name.

What I did

• make them accept props as a native HTML element.
• added class name generator for FieldSet component, and applied it.

@isiahmeadows thanks for clarifying, then maybe the proposal text should be updated ... but to be sure we're on the same page:

<ul id="list">
  <li>first task</li>
  <!-- come comment -->
</ul>

Assuming a new item such as:

const task = document.createElement('li');
task.textContent = 'last task';

list.insertAfter(task, null)

would produce:

<ul id="list">
  <li>first task</li>
  <!-- come comment -->
  <li>last task</li>
</ul>

while ...

list.insertAfter(task, list.lastElementChild)

would produce:

<ul id="list">
  <li>first task</li>
  <li>last task</li>
  <!-- come comment -->
</ul>

did I get it right?

This is whole callstack:

Call Stack
eval
node_modules/relay-compiler/lib/core/GraphQLCompilerProfiler.js (192:20)
Object../node_modules/relay-compiler/lib/core/GraphQLCompilerProfiler.js
file:///workspace/.next/static/chunks/pages/_app.js (3812:1)
Object.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
node_modules/relay-compiler/lib/core/CompilerContext.js (13:15)
Object../node_modules/relay-compiler/lib/core/CompilerContext.js
file:///workspace/.next/static/chunks/pages/_app.js (3790:1)
Object.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
webpack-internal:///./node_modules/@graphql-tools/relay-operation-optimizer/index.esm.js (15:97)
Module../node_modules/@graphql-tools/relay-operation-optimizer/index.esm.js
file:///workspace/.next/static/chunks/pages/_app.js (227:1)
Module.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
webpack-internal:///./node_modules/@graphql-codegen/visitor-plugin-common/index.esm.js (73:99)
Module../node_modules/@graphql-codegen/visitor-plugin-common/index.esm.js
file:///workspace/.next/static/chunks/pages/_app.js (205:1)
Module.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
webpack-internal:///./.yalc/@graphql-codegen/typescript-rtk-query/dist/index.esm.js (20:97)
Module../.yalc/@graphql-codegen/typescript-rtk-query/dist/index.esm.js
file:///workspace/.next/static/chunks/pages/_app.js (249:1)
Module.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
webpack-internal:///./src/services/api/api.ts (7:95)
Module../src/services/api/api.ts
file:///workspace/.next/static/chunks/pages/_app.js (304:1)
Module.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
webpack-internal:///./src/services/api/index.ts (5:62)
Module../src/services/api/index.ts
file:///workspace/.next/static/chunks/pages/_app.js (315:1)
Module.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
webpack-internal:///./src/store.ts (6:71)
Module../src/store.ts
file:///workspace/.next/static/chunks/pages/_app.js (326:1)
Module.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
webpack-internal:///./src/pages/_app.tsx (5:64)
Module../src/pages/_app.tsx
file:///workspace/.next/static/chunks/pages/_app.js (293:1)
Module.options.factory
/_next/static/chunks/webpack.js (685:31)
__webpack_require__
file:///workspace/.next/static/chunks/webpack.js (37:33)
fn
/_next/static/chunks/webpack.js (348:21)
eval
node_modules/next/dist/build/webpack/loaders/next-client-pages-loader.js?page=%2F_app&absolutePagePath=private-next-pages%2F_app.tsx! (5:15)
eval
node_modules/next/dist/client/route-loader.js (294:22)

dfsf

If child is null, this prepends node as the first child.

with insertBefore, if child is null the element is appended (like appendChild would do) ... I find this proposed behavior here a bit controversial ... the before "appends with null, the after "prepend" with null as first child ... am I the only one not fully getting the use case for prepending as first child with a method called after ?

@WebReflection Sorry, got my directions switched up. elem.insertBefore(node, null) prepends, and I meant for elem.insertAfter(node, null) to append.

Are there benchmarks for this? @smaug---- @rniwa thoughts?

@annevk I don't have any benchmarks on the ready as this was years ago (though little's changed since). The main thing is C++ showing up high on profiles, and of course I want to avoid that. And .insertAfter is a bit simpler natively than in userland, or I'd use it:

function insertAfter(parent, child, refNode) {
    parent.insertBefore(child, refNode != null ? refNode.nextSibling : null)
}

It seems okay to add this assuming there is no web compatibility issue. It looks like there is at least one (semi?) popular library which implements insertAfter so someone needs to assess the web compatibility risk.

@rniwa Not sure it's that significant of a risk when they also overwrite Element#insertBefore in exactly the same way.

If child is null, this prepends node as the first child.

with insertBefore, if child is null the element is appended (like appendChild would do) ... I find this behavior a bit controversial ... the before "appends with null, the after "prepend" with null as first child ... am I the only one not fully getting the use case for prepending as first child with a method called after ?