kaikai221のブログ

kaikaiについてのブログです

5/4

今日やる事

6-7TOEIC

7-8:30チーム開発の修正

8:30-9:00オンライン英会話

 

10:00-18:00インターン:Authorとリファクタリングプレビュー機能

 

所感

朝にやりたいことがちゃんとできてないと感じてる。

夜はもう少し勉強に集中できるのではないかと感じてるのでもっと勉強に集中できるようにしよう。

 

5/3

今日から朝にやった勉強内容と夜にやった勉強内容をまとめてみる。

朝やったこと

5:30-8:30

・オンライン英会話

・自己分析

11-18

・コーディングテスト

・Udemyはハッシュテーブル

・自作ブログの修正

所感

午後は正直あまり進まなかった。

もう少し進みを早くするべきだと思う。

やってる密度を濃くするように心がけよう。

 

 

 

 

3時間でここまでしか進まなかったのはやばいと思うので対策が必要。

今何にをもに悩んでいるのか。

それは就活に悩んでいる。

別に就活しなくてもいいやん!就活しなくても今のインターン先で働けるやん。

もし今のインターン先でもダメだった身内の営業やどっかの営業のインターンにどこかしら引っかかるやん。

 

ならどうするのが一番いいか。それは目の前のことに全力で取り組む。

エンジニアリングに全力で取り組むことだと思う。

 

とりあえずは3年はエンジニアとして全力で取り組む。

 

就活はどうでもいい。

 

-------------------

午後からやること

アルゴリズムのUdmey対策

コーディングテスト受ける

チーム開発の修正 

 

fowarding ref について

Forwarding Refs – React

 

編集

 

Forwarding Refs

ref forwarding はchildrenコンポーネントのを通して自動的にrefを渡すテクニックです。

これは全てのコンポーネントに必要なわけではありません。しかし、使い回し可能なコンポーネントを使うときに有効になってくる。使い方を今から説明します。

 

 Forwarding refs to DOM components

nativeDOMボタンをレンダーする FancyButton componentのケースを考えてみよう。

function FancyButton(props) {
  return (
    <button className="FancyButton">
      {props.children}
    </button>
  );
}

 

React components hide their implementation details, including their rendered output. Other components using FancyButton usually will not need to obtain a ref to the inner button DOM element. This is good because it prevents components from relying on each other’s DOM structure too much.

Reactコンポーネントレンダリングされた出力を含む実装の詳細を非表示にします。

FancyButtonを用いた他のコンポーネントは内側のbutton DOM要素のrefを取得する必要はありません。これはDOM構造の依存しすぎるのを防ぐことができます。

Although such encapsulation is desirable for application-level components like FeedStory or Comment, it can be inconvenient for highly reusable “leaf” components like FancyButton or MyTextInput. These components tend to be used throughout the application in a similar manner as a regular DOM button and input, and accessing their DOM nodes may be unavoidable for managing focus, selection, or animations.

Ref forwarding is an opt-in feature that lets some components take a ref they receive, and pass it further down (in other words, “forward” it) to a child.

In the example below, FancyButton uses React.forwardRef to obtain the ref passed to it, and then forward it to the DOM button that it renders:

 

const FancyButton = React.forwardRef((props, ref) => (  <button ref={ref} className="FancyButton">    {props.children}
  </button>
));

// You can now get a ref directly to the DOM button:
const ref = React.createRef();
<FancyButton ref={ref}>Click me!</FancyButton>;

 

This way, components using FancyButton can get a ref to the underlying button DOM node and access it if necessary—just like if they used a DOM button directly.

Here is a step-by-step explanation of what happens in the above example:

  1. We create a React ref by calling React.createRef and assign it to a ref variable.
  2. We pass our ref down to <FancyButton ref={ref}> by specifying it as a JSX attribute.
  3. React passes the ref to the (props, ref) => ... function inside forwardRef as a second argument.
  4. We forward this ref argument down to <button ref={ref}> by specifying it as a JSX attribute.
  5. When the ref is attached, ref.current will point to the <button> DOM node.

Note

The second ref argument only exists when you define a component with React.forwardRef call. Regular function or class components don’t receive the ref argument, and ref is not available in props either.

Ref forwarding is not limited to DOM components. You can forward refs to class component instances, too.

 Note for component library maintainers

When you start using forwardRef in a component library, you should treat it as a breaking change and release a new major version of your library. This is because your library likely has an observably different behavior (such as what refs get assigned to, and what types are exported), and this can break apps and other libraries that depend on the old behavior.

Conditionally applying React.forwardRef when it exists is also not recommended for the same reasons: it changes how your library behaves and can break your users’ apps when they upgrade React itself.

 Forwarding refs in higher-order components

This technique can also be particularly useful with higher-order components (also known as HOCs). Let’s start with an example HOC that logs component props to the console:

function logProps(WrappedComponent) {  class LogProps extends React.Component {
    componentDidUpdate(prevProps) {
      console.log('old props:', prevProps);
      console.log('new props:', this.props);
    }

    render() {
      return <WrappedComponent {...this.props} />;    }
  }

  return LogProps;
}

 

The “logProps” HOC passes all props through to the component it wraps, so the rendered output will be the same. For example, we can use this HOC to log all props that get passed to our “fancy button” component:

class FancyButton extends React.Component {
  focus() {
    // ...
  }

  // ...
}

// Rather than exporting FancyButton, we export LogProps.
// It will render a FancyButton though.
export default logProps(FancyButton);

 

There is one caveat to the above example: refs will not get passed through. That’s because ref is not a prop. Like key, it’s handled differently by React. If you add a ref to a HOC, the ref will refer to the outermost container component, not the wrapped component.

This means that refs intended for our FancyButton component will actually be attached to the LogProps component:

import FancyButton from './FancyButton';

const ref = React.createRef();
// The FancyButton component we imported is the LogProps HOC.
// Even though the rendered output will be the same,
// Our ref will point to LogProps instead of the inner FancyButton component!
// This means we can't call e.g. ref.current.focus()
<FancyButton
  label="Click Me"
  handleClick={handleClick}
  ref={ref}/>;

 

Fortunately, we can explicitly forward refs to the inner FancyButton component using the React.forwardRef APIReact.forwardRef accepts a render function that receives props and ref parameters and returns a React node. For example:

function logProps(Component) {
  class LogProps extends React.Component {
    componentDidUpdate(prevProps) {
      console.log('old props:', prevProps);
      console.log('new props:', this.props);
    }

    render() {
      const {forwardedRef, ...rest} = this.props;
      // Assign the custom prop "forwardedRef" as a ref
      return <Component ref={forwardedRef} {...rest} />;    }
  }

  // Note the second param "ref" provided by React.forwardRef.
  // We can pass it along to LogProps as a regular prop, e.g. "forwardedRef"
  // And it can then be attached to the Component.
  return React.forwardRef((props, ref) => {    return <LogProps {...props} forwardedRef={ref} />;  });}

 

 Displaying a custom name in DevTools

React.forwardRef accepts a render function. React DevTools uses this function to determine what to display for the ref forwarding component.

For example, the following component will appear as ”ForwardRef” in the DevTools:

 

const WrappedComponent = React.forwardRef((props, ref) => {
  return <LogProps {...props} forwardedRef={ref} />;
});

 

If you name the render function, DevTools will also include its name (e.g. ”ForwardRef(myFunction)”):

 

const WrappedComponent = React.forwardRef(
  function myFunction(props, ref) {
    return <LogProps {...props} forwardedRef={ref} />;
  }
);

 

You can even set the function’s displayName property to include the component you’re wrapping:

 

function logProps(Component) {
  class LogProps extends React.Component {
    // ...
  }

  function forwardRef(props, ref) {
    return <LogProps {...props} forwardedRef={ref} />;
  }

  // Give this component a more helpful display name in DevTools.
  // e.g. "ForwardRef(logProps(MyComponent))"
  const name = Component.displayName || Component.name;  forwardRef.displayName = `logProps(${name})`;
  return React.forwardRef(forwardRef);
}

 

GitHub Actions

GitHub Actionsの紹介

 

GitHub Actionsのコアな概念と様々な機能について学び、あなたのリポジトリにautomation機能を追加する方法を例を用いて示します。

 

概要

 

 

GitHub Actionsはあなたのソフトウェア開発のライフサイクル内のタスクを自動かするのに役立ちます。GitHub Actionsはイベントドリブンでそしてそれは指定したイベントが生じた後に一連のコマンドを叩くことができます。例えば、誰かがプルリクエストをリポジトリに出すたびに、ソフトウェアテストスクリプトで実行するコマンドを自動的に走らせることができます。

 

この図はいかにしてソフトウェアテストスクリプトGitHub Actionsを使って自動的に走らせているかを示しています。一つのイベントが自動的にワークフローにトリガーされたその時にjobが含まれている。jobは次にどのアクションを走らせるのかを順番にコントロールするために使います。これらのアクションはソフトウェアテストを自動かするためのアクションです。

 

 

Workflow overview

GitHub Actionsのの機能

下の図はjobを一緒に走らせるための多様なGitHub Actions機能のリストです。

あなたはこれらお互いがどのように相互作用しているかをみることができます。

Component and service overview

Workflows

workflowはリポジトリーに追加するための自動化手順です。ワークフローは一つ以上のjobsから成り立っており、イベントによってスケジュール化、またトリガーできる。ワークフローは通常test、パッケージ、releaseのbuild時またはgithubにdeployした時に使うことでができます。

Events

イベントはワークフローによってトリガーした特定の活動です。例えば、活動は誰かがリポジトリーにpushした時またはイシューやプルリクエストが作られた時にgithubから発信することができる。また、外部イベントが怒った時にrepository dispatch webhook を用いてワークフローをトリガーできる。ワークフローのトリガーで使われたイベントのリストをコンパイルするためにはEvents that trigger workflows.こちらを拝見してください

Jobs

jobは同じランナーで行う一連のステップです。デフォルトでは多くのjobのワークフローはこれらのjobと並行して作動する。jobを順序立って行うこともできます。例えば、ワークフローはビルドの状態と依存してテストをジョブするビルドとテストの二つの一連のjobを持つことができる。もしbuildのジョブが失敗したらテストジョブは作動しません。

Steps

ステップはjobないでコマンドを走らせることができる個人タスクです。

ステップはactionまたはshellコマンドを使うことができる。jobないのそれぞれのstepは同じrunnrでjobないのアクションは他とデータをシェアすることができる。

Actions

actionはjobを作るためのステップ内を結びつけるスタンドアロンコマンドである。

actionはワークフローブロック内をbuildしている最小のポータブルである。自分のactionを作ったり、github comunityで作られているアクションを使うことができる。workflowないでactionを使うために、stepとして含める必要がある。

Runners

runnerはGitHub Actions runner application でインストールされた、サーバーである。GitHubを使うことによってrunnerを使うことができる。または、自分自身でも作れる。runnnerはジョブを実行し、進捗のログを報告しその結果をGitHubに返す。GitHubのランナーはUbuntu Linux, Microsoft Windows, and macOSに基づいており、仮想の新鮮な環境で実行されます。もし自分好みのカスタマイズをしたかったら、オリジナルrunnerを作ることができる。Hosting your own runnersその場合ここ見てね。

Create an example workflow

GitHub Actions uses YAML syntax to define the events, jobs, and steps. These YAML files are stored in your code repository, in a directory called .github/workflows.

You can create an example workflow in your repository that automatically triggers a series of commands whenever code is pushed. In this workflow, GitHub Actions checks out the pushed code, installs the software dependencies, and runs bats -v.

GitHub ActionsはYAML構文を使ってイベントやステップを定義しているよ。yaml構文は.github/workflowsディレクトリで書いてね。コードをpushした時いつでも使えるよ。GitHub Actionsの中でもchecks outとパッケージのインストールが必要だよ。

 

  1. In your repository, create the .github/workflows/ directory to store your workflow files.
  2. In the .github/workflows/ directory, create a new file called learn-github-actions.yml and add the following code.
    name: learn-github-actions
    on: [push]
    jobs:
      check-bats-version:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v2
          - uses: actions/setup-node@v1
          - run: npm install -g bats
          - run: bats -v
    
  3. Commit these changes and push them to your GitHub repository.

Your new GitHub Actions workflow file is now installed in your repository and will run automatically each time someone pushes a change to the repository. For details about a job's execution history, see "Viewing the workflow's activity."

Understanding the workflow file

To help you understand how YAML syntax is used to create a workflow file, this section explains each line of the introduction's example:

name: learn-github-actions
Optional - The name of the workflow as it will appear in the Actions tab of the GitHub repository.
on: [push]
Specify the event that automatically triggers the workflow file. This example uses the push event, so that the jobs run every time someone pushes a change to the repository. You can set up the workflow to only run on certain branches, paths, or tags. For syntax examples including or excluding branches, paths, or tags, see "Workflow syntax for GitHub Actions."
jobs:
Groups together all the jobs that run in the learn-github-actions workflow file.
check-bats-version:
Defines the name of the check-bats-version job stored within the jobs section.
  runs-on: ubuntu-latest
Configures the job to run on an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "Workflow syntax for GitHub Actions."
  steps:
Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell command.
    - uses: actions/checkout@v2
The uses keyword tells the job to retrieve v2 of the community action named actions/checkout@v2. This is an action that checks out your repository and downloads it to the runner, allowing you to run actions against your code (such as testing tools). You must use the checkout action any time your workflow will run against the repository's code or you are using an action defined in the repository.
    - uses: actions/setup-node@v1
This action installs the node software package on the runner, giving you access to the npm command.
    - run: npm install -g bats
The run keyword tells the job to execute a command on the runner. In this case, you are using npm to install the bats software testing package.
    - run: bats -v
Finally, you'll run the bats command with a parameter that outputs the software version.

Visualizing the workflow file

In this diagram, you can see the workflow file you just created and how the GitHub Actions components are organized in a hierarchy. Each step executes a single action or shell command. Steps 1 and 2 use prebuilt community actions. Steps 3 and 4 run shell commands directly on the runner. To find more prebuilt actions for your workflows, see "Finding and customizing actions."

Workflow overview

Viewing the job's activity

Once your job has started running, you can see a visualization graph of the run's progress and view each step's activity on GitHub.

  1. On GitHub, navigate to the main page of the repository.

  2. Under your repository name, click Actions.

    Navigate to repository

     

  3. In the left sidebar, click the workflow you want to see.

    Screenshot of workflow results

     

  4. Under "Workflow runs", click the name of the run you want to see.

    Screenshot of workflow runs

     

  5. Under Jobs or in the visualization graph, click the job you want to see.

    Select job

     

  6. View the results of each step.

    Screenshot of workflow run details

     

eslint-plugin-import について

import/order

import/order:moduleのimport 順番で規則を適用する。

 

require()/import 文の順番で規則を適用する。

--fixを用いてこのルールに従って報告された問題は自動的に修正される。

順番は以下の通りに示しております。

// 1. node "builtin" modules
import fs from 'fs';
import path from 'path';
// 2. "external" modules
import _ from 'lodash';
import chalk from 'chalk';
// 3. "internal" modules
// (if you have configured your path or webpack to handle your internal paths differently)
import foo from 'src/foo';
// 4. modules from a "parent" directory
import foo from '../foo';
import qux from '../../foo/qux';
// 5. "sibling" modules from the same or a sibling's directory
import bar from './bar';
import baz from './bar/baz';
// 6. "index" of the current directory
import main from './';
// 7. "object"-imports (only available in TypeScript)
import log = console.log;

指定されていないimportsは無視されるのでimportした順番は需要です。

分はes6のimport シンタックスを用いてrequireの前に書かなければならない。

Fail

import _ from 'lodash';
import path from 'path'; // `path` import should occur before import of `lodash`

// -----

var _ = require('lodash');
var path = require('path'); // `path` import should occur before import of `lodash`

// -----

var path = require('path');
import foo from './foo'; // `import` statements must be before `require` statement

Pass

import path from 'path';
import _ from 'lodash';

// -----

var path = require('path');
var _ = require('lodash');

// -----

// Allowed as ̀`babel-register` is not assigned.
require('babel-register');
var path = require('path');

// -----

// Allowed as `import` must be before `require`
import foo from './foo';
var path = require('path');

Options

This rule supports the following options:

このルールは以下の通りのオプションをサポートしております。

groups: [array]:

How groups are defined, and the order to respect. groups must be an array of string or [string]. The only allowed strings are: "builtin""external""internal""unknown""parent""sibling""index""object". The enforced order is the same as the order of each element in a group. Omitted types are implicitly grouped together as the last element. Example:

グループの定義方法と尊重する順序.groupsはstringの配列でなければならない。以下のstringが有効である。"builtin""external""internal""unknown""parent""sibling""index""object".

施行される順番はグループの各要素の順番と同じである。

[
  'builtin', // Built-in types は最初
  ['sibling', 'parent'], // Then sibling and parent types.次に兄弟タイプと親タイプ 。それらは一緒に混ぜることができます。
  'index', // 次にindexファイル
  'object',

  最後に:internalとexternlのタイプ ]

The default value is ["builtin", "external", "parent", "sibling", "index"].

デフォルトのvalue["builtin", "external", "parent", "sibling", "index"].である。

You can set the options like this:

あなたはこのようにセットすることもできる

"import/order": ["error", {"groups": ["index", "sibling", "parent", "internal", "external", "builtin", "object"]}]

pathGroups: 

To be able to group by paths mostly needed with aliases pathGroups can be defined.

Properties of the objects

エイリアスで最も必要とされているパスで グループ化できるようにするためには、pathGroupesを定義できます。

property required type description
pattern x string

 

パスのためにミニマッチパターンはこのグループになる。(builtinsやexternalsでは使われない)

patternOptions   object

ミニマッチのためのオプション

default: { nocomment: true }

group x string

 

認可されたグループのひとつ。パスグループはこのグループと相対的にポジショニングされる

position   string

パスグループのポジションををグループとして定義する場所で"after"か"before"を用いる。

もしpathGroupがグループのようにポジションされていなかったら無効化される。

{
  "import/order": ["error", {
    "pathGroups": [
      {
        "pattern": "~/**",
        "group": "external"
      }
    ]
  }]
}

pathGroupsExcludedImportTypes:

This defines import types that are not handled by configured pathGroups. This is mostly needed when you want to handle path groups that look like external imports.

設定したパスグループにハンドルしないimport typeを定義する。

これはexternal importのようなパスグループを扱うときに必要になってくる。

Example:

{
  "import/order": ["error", {
    "pathGroups": [
      {
        "pattern": "@app/**",
        "group": "external",
        "position": "after"
      }
    ],
    "pathGroupsExcludedImportTypes": ["builtin"]
  }]
}

The default value is ["builtin", "external"].

newlines-between

import間の新しいlineを施行または排除

 

  • もしignoreならimport group間のlineエラーは表示しない
  • もしalwaysならimport間の新しいlineを作る。そしてグループ間の新しいlineは禁止される。多くのimport間のlineを防ぐためにno-multiple-empty-linesが用いられる
  • もしalways-and-inside-groupsをセットしたらimportグループ内のk許可された新しいlinesをのぞく.
  • もしneverをセットしたなら、import セクションにいかなるlineも作れない。

デフォルトは以下の通りである。

/* eslint import/order: ["error", {"newlines-between": "always"}] */
import fs from 'fs';
import path from 'path';
import index from './';
import sibling from './foo';
/* eslint import/order: ["error", {"newlines-between": "always-and-inside-groups"}] */
import fs from 'fs';

import path from 'path';
import index from './';
import sibling from './foo';
/* eslint import/order: ["error", {"newlines-between": "never"}] */
import fs from 'fs';
import path from 'path';

import index from './';

import sibling from './foo';

while those will be valid:

/* eslint import/order: ["error", {"newlines-between": "always"}] */
import fs from 'fs';
import path from 'path';

import index from './';

import sibling from './foo';
/* eslint import/order: ["error", {"newlines-between": "always-and-inside-groups"}] */
import fs from 'fs';

import path from 'path';

import index from './';

import sibling from './foo';
/* eslint import/order: ["error", {"newlines-between": "never"}] */
import fs from 'fs';
import path from 'path';
import index from './';
import sibling from './foo';

アルファベット順にする。

import パスのアルファベット順に基づいて順番にする。

  • order:ascを使うことのよって上から順番をアルファベット順にすることができる。
  • caseInsensitive: use true to ignore case, and false to consider case (default: false).
  • caseInsensitive:trueににすることにcaseを無視する。falseによってcasewを考慮する。

Example setting:

alphabetize: {
  order: 'asc', /* sort in ascending order. Options: ['ignore', 'asc', 'desc'] */
  caseInsensitive: true /* ignore case. Options: [true, false] */
}

This will fail the rule check:

/* eslint import/order: ["error", {"alphabetize": {"order": "asc", "caseInsensitive": true}}] */
import React, { PureComponent } from 'react';
import aTypes from 'prop-types';
import { compose, apply } from 'xcompose';
import * as classnames from 'classnames';
import blist from 'BList';

While this will pass:

/* eslint import/order: ["error", {"alphabetize": {"order": "asc", "caseInsensitive": true}}] */
import blist from 'BList';
import * as classnames from 'classnames';
import aTypes from 'prop-types';
import React, { PureComponent } from 'react';
import { compose, apply } from 'xcompose';

Related

 

 

import/orderを使うことによってimportの順番を整えることができる。

絶対パスの指定につまづいてしまったが、パスグループの指定でその都度パスグループの指定をしなければいけなかった模様。

例えばimport {yourname} /component/yournameのように絶対パス指定のimport先も対応させるためには

{
pattern: '/**',
group: 'internal',
position: 'after',
},

 

このように/の中身を全て取得してinternalグループとして扱って順序は一番最後にするといった内容にしなければいけなかった。

 

 

1日目

Yarn link

開発間のシンボリックパッケージフォルダー

 

開発のために、パッケージは他のプロジェクトと結びつけることができる。これは新しい機能のテストにかなり有効かつ他のプロジェクト内のマニフェスト自体のパッケージの中のisssueをデバックするのにかなり有効である。

 

 

これらは二つのコマンドを促進する

 

このコマンドはあなたがリンクしたいパッケージフォルダー内で走る。

例えば、あなたがreactを走らせて、react-relay内の問題をデバックするためにローカルバージョンの使いたいときに、単純にreactプロジェクト内でyarn linkを走らせる。

 

現在のプロジェクト内でテストしたいのなら他のパッケージであるyarn link [package..]を使いなさい。上の例に従うことによって、react-relayプロジェクト内であなたは以前リンクしたあなたのreactのローカルバージョンを使うためにyarn link reactを走らせてみてください!

 

Complete example, assuming two project folders react and react-relay next to each other:

次の二つを比較する例は以下の通りです。

$ cd react
$ yarn link
yarn link vx.x.x
success Registered "react".
info You can now run `yarn link "react"` in the projects where you want to use this module and it will be used instead.
$ cd ../react-relay
$ yarn link react
yarn link vx.x.x
success Registered "react".

これはreactプロジェクトのlocalコーピーとリンクするためにreact-relay/node_modules/reactの名前のシンボリックを作り出す。

 linkは~/.config/yarn/link内に登録される。もし違うフォルダーを特定したい場合

yarn link --link-folder path/to/dir/コマンドを走らせることができる。

 

このプロセスを反対にすると、単純にyarn unlinkまたは、yarn unlink [package]を使ってみてはいかがでしょうか?

 
[まとめ]
 
 reactのローカル環境でデバックしたいときにyarn linkを使う?

30daysチャレンジ

久しぶりの30daysチャレンジになりましたが、今回は英語のドキュメントを翻訳して簡単にまとめるというものをして行きたいと思います。

 

というのも、業務で公式ドキュメントを読む幾何が増えたのですが普段からドキュメントを読むことに慣れていないため時間をかなり浪費させてしまったからです。そのため今回は会社で使われているJavaScriptのライブラリや公式ドキュメントの一部を翻訳して簡素にまとめるという作業をしたいと思います。

 

やる時間帯としましては、8:30-10:00の間とします。