profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/koba04/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Toru Kobayashi koba04 @cybozu, SmartHR Japan https://koba04.com/ Web Application Developer

koba04/canvas-exif-orientation 14

draw a image on a canvas dependent on Exif Orientation.

koba04/backbone-boilerplate 13

my boilerplate of backbone.js

koba04/ecma-version-validator-webpack-plugin 13

A wepback plugin to verify ECMAScript version for bundle files.

koba04/cookbooks-anyenv 2

anyenv cookbook for chef

koba04/dotfiles 2

manage dotfiles

koba04/a11y-guidelines 0

FRESH! Accessibility Guidelines

koba04/actix-website 0

The Actix website.

issue commentfacebook/react

React 18: react-router@v5 is breaking in the Strict Mode (strict effects)

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

Jack-Works

comment created time in 14 minutes

push eventkufu/smarthr-ui

wmoai

commit sha 99d9096b416bb93a87a707dceaf1eb50002f7b5c

chore: fix exporting type (#1661)

view details

renovate[bot]

commit sha 5b4992aa319db1de43ebe85581f3fb200f6267d4

chore(deps): update babel monorepo to ^7.14.5 (#1663) Co-authored-by: Renovate Bot <bot@renovateapp.com> Co-authored-by: Shiho Ishitoko <cidermitaina@gmail.com>

view details

renovate[bot]

commit sha 6f0ec77b84e2f7862d0ae0e2591a4f62297b8cd6

chore(deps): update dependency husky to v6 (#1649) * chore(deps): update dependency husky to v6 * update: husky v6 に上げる Co-authored-by: Renovate Bot <bot@renovateapp.com> Co-authored-by: Yuta Yamamoto <ftbae1@gmail.com>

view details

renovate[bot]

commit sha f51f001b5cf117008f16dbb1890b2a6752461167

chore(deps): update dependency react-transition-group to ^4.4.2 (#1623) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha b887ecf2f1f01084e754570b966d2bfb553156b9

chore(deps): update dependency polished to ^4.1.3 (#1645) Co-authored-by: Renovate Bot <bot@renovateapp.com> Co-authored-by: Masakatsu Tokita <lily.yarn.5@gmail.com>

view details

wmoai

commit sha 0809cbb4e14ea196ad7736b5511ba46915f78e9c

feat: add default class (#1659) Co-authored-by: Shiho Ishitoko <cidermitaina@gmail.com> Co-authored-by: nabeliwo <hiroki.c.watanabe@gmail.com>

view details

wmoai

commit sha 925790a11ac7b1b5095971de7d800e3daea12e03

feat: `Icon` にデフォルトクラスを追加 (SHRUI-269) (#1651) * feat: add default class * test: update snapshot Co-authored-by: nabeliwo <hiroki.c.watanabe@gmail.com>

view details

wmoai

commit sha b7ddfa959f712d891777953a41abead0eaf74df5

feat: `HeadlineArea` の class 名と属性の改善 (SHRUI-268) (#1641) * feat: add default class * fix: modify to pass default attributes Co-authored-by: nabeliwo <hiroki.c.watanabe@gmail.com>

view details

nabeliwo

commit sha 0994108ea672b7c352a1b29a9e9a4005049063bd

fix: CompactInformationPanel に className を渡せるようにする (#1669)

view details

Yuta Yamamoto

commit sha 4d0e17d63accbb4d0b39a49a830ae7dbe2af5021

feat: improve attributes for Footer (#1633) Co-authored-by: nabeliwo <hiroki.c.watanabe@gmail.com>

view details

Renovate Bot

commit sha 8bf0e82528c18e2d789edb87cda43cbcf18f85ef

chore(deps): update storybook monorepo to ^6.2.9

view details

push time in 27 minutes

Pull request review commentwhatwg/html

Define <meta media>. Fixes #6495.

 interface <dfn>HTMLMetaElement</dfn> : <span>HTMLElement</span> {    </div> +  <p>The <dfn element-attr for="meta"><code data-x="attr-meta-media">media</code></dfn> attribute+  says which media the metadata applies to. The value must be a <span>valid media query+  list</span>. The <dfn attribute+  for="HTMLMetaElement"><code data-x="dom-meta-media">media</code></dfn> IDL attribute must+  <span>reflect</span> the content attributes of the same name. Unless the <code+  data-x="attr-meta-name">name</code> is <code data-x="meta-theme-color">theme-color</code>, the+  <code data-x="attr-meta-media">media</code> attribute is purely advisory.</p>

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)

hober

comment created time in 32 minutes

fork amanthegreatone/redux-store-structure-patterns

Patterns for Redux Store with a data structure that has nested relationships

fork in 43 minutes

pull request commenttc39/ecma262

Some changes to make the doc more beginner-friendly

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

tomayac

comment created time in 44 minutes

pull request commentwhatwg/html

Define <meta media>. Fixes #6495.

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

hober

comment created time in an hour

PR opened adobe/react-spectrum

Integrate DocSearch

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

+117 -0

0 comment

3 changed files

pr created time in an hour

Pull request review commenthttpwg/http-extensions

Add a section for http prioritization in transport retransmission

 signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame.  +# Retransmission Scheduling++A transport may detect packet losses and then retranmit lost information to+provide reliability. Examples include TCP and QUIC. While this document+specifies HTTP layer prioritization, its effectiveness can be further achieved+if transport layer also respect such priorities. Besides scheduling new data,+transport implementations MAY also consider stream priorities during+retransmission. In this section we will use QUIC as an example to discusss a+couple scenarios an implementation need to consider.++{{!I-D.ietf-quic-transport}}, Section 13.3 states that endpoints SHOULD +prioritize retransmission over sending new data, unless otherwise specified by+application. When an HTTP/3 application uses priority scheme defined in this +document, the QUIC transport layer MAY take stream priorities as input to +scheduling the sending of both retransmission data and new data. For example, +if one stream with higher urgency has new data to send and another stream with +lower urgency has retransmission data to send, a QUIC transport may choose to +schedule the higher urgency new data before the lower urgency retransmission+data.

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

yangchi

comment created time in an hour

push eventfacebookexperimental/Recoil

github-actions[bot]

commit sha ecff3441456fbbf2c41f49f717fbbdc7b87b9e35

Publishing a nightly build as 0.3.1

view details

push time in an hour

issue commentreduxjs/redux-toolkit

RTKQ with graphql-codegen weird error

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.

nenadfilipovic

comment created time in 2 hours

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

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

isiahmeadows

comment created time in 2 hours

issue commentreduxjs/redux-toolkit

RTKQ with graphql-codegen weird error

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

nenadfilipovic

comment created time in 2 hours

IssuesEvent

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

@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)
isiahmeadows

comment created time in 2 hours

issue closedreduxjs/redux-toolkit

RTKQ with graphql-codegen weird error

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.

closed time in 2 hours

nenadfilipovic

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

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

isiahmeadows

comment created time in 2 hours

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

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

isiahmeadows

comment created time in 2 hours

issue commentwhatwg/fetch

Trailer support in the API

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.

annevk

comment created time in 2 hours

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

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

isiahmeadows

comment created time in 2 hours

issue commentreduxjs/redux-toolkit

RTKQ with graphql-codegen weird error

With fetchBaseQuery it works flawless:

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

comment created time in 2 hours

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

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.

isiahmeadows

comment created time in 2 hours

issue commentwhatwg/fetch

Trailer support in the API

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.

annevk

comment created time in 2 hours

push eventkufu/smarthr-ui

Yuta Yamamoto

commit sha 4d0e17d63accbb4d0b39a49a830ae7dbe2af5021

feat: improve attributes for Footer (#1633) Co-authored-by: nabeliwo <hiroki.c.watanabe@gmail.com>

view details

push time in 2 hours

PR merged kufu/smarthr-ui

Reviewers
feat: improve attributes for Footer

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.
+49 -13

1 comment

2 changed files

yt-ymmt

pr closed time in 2 hours

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

@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?

isiahmeadows

comment created time in 2 hours

issue commentreduxjs/redux-toolkit

RTKQ with graphql-codegen weird error

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)
nenadfilipovic

comment created time in 2 hours

issue commentreactjs/reactjs.org

compound components not mentioned in docs

dfsf

surajnarsale

comment created time in 2 hours

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

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.

isiahmeadows

comment created time in 2 hours

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

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.

isiahmeadows

comment created time in 2 hours

issue commentwhatwg/dom

Suggestion: `Node.insertAfter(newNode, referenceNode)`

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 ?

isiahmeadows

comment created time in 2 hours