launch.jsonファイルに関して
launch.json設定
現行の開発環境の設定になります。
とりあえず、フロントとバックエンドとでそれぞれデバッグ項目を作成し、あとは
両方一括実行できる選択肢を用意しています。
下に各項目の記載をしてあります。
{
"version": "0.2.0",
"configurations": [
{
"name": "BackEnd Debug",
"type": "node",
"request": "launch",
"runtimeExecutable": "node",
"runtimeArgs": ["--loader", "ts-node/esm", "--require", "dotenv/config"],
"program": "${workspaceFolder}/src/server.ts",
"cwd": "${workspaceFolder}",
"console": "integratedTerminal",
"skipFiles": ["/**"],
"sourceMaps": true,
"autoAttachChildProcesses": true
},
{
"name": "FrontEnd Server",
"type": "node-terminal",
"request": "launch",
"command": "npm run start:react"
},
{
"name": "FrontEnd(chrome)",
"type": "chrome",
"request": "launch",
"url": "http://localhost:3000",
"webRoot": "${workspaceFolder}/src",
"preLaunchTask": "start-react",
"sourceMapPathOverrides": {
"webpack:///*": "${webRoot}/*"
}
}
],
"compounds": [
{
"name": "FullStack Debug",
"configurations": [
"FrontEnd(chrome)",
"BackEnd Debug" ]
},
{
"name": "FrontEnd(React+Chrome)",
"configurations": [
"FrontEnd Server",
"FrontEnd(chrome)"
]
}
]
}
各項目詳細
runtimeExecutable: node
使用する実行ファイル（Node.js）
runtimeArgs:
-
- loader ts-node/esm : TypeScript を ESM として直接実行
- require dotenv/config : .env を自動読み込み
program:
デバッグ対象のエントリーポイント
cwd:
実行時のカレントディレクトリ
console: integratedTerminal
VS Code の統合ターミナルで実行
skipFiles:
Node.js 内部コードをステップ実行から除外
sourceMaps: true
TypeScript の source map を有効化
autoAttachChildProcesses: true
子プロセスも自動でデバッグ対象にする
--- FrontEnd Server ---
name:
フロントエンド開発サーバー起動用
type: node-terminal
ターミナルコマンドを実行する設定
command:
React 開発サーバー起動コマンド
--- FrontEnd(chrome) ---
type: chrome
Chrome を起動してフロントエンドをデバッグ
url:
デバッグ対象の Web アプリ URL
webRoot:
source map 解決の基準ディレクトリ
preLaunchTask:
Chrome 起動前に実行する task
sourceMapPathOverrides:
webpack の source map パスをローカルに対応付ける
[compounds]
複数のデバッグ設定を同時に起動
--- FullStack Debug ---
バックエンド + フロントエンドを同時デバッグ
tsconfigファイルの役割まとめ
動作環境を構築する際に必要なtsconfigファイルの個人的なまとめになります。
一度設定すると変更することは少ないと思いますが、念のため、メモ書きで残します。
設定ファイルがいろいろあってごちゃごちゃするので、まだ頭の中で
整理できていないような気がします。
tsconfig.json概要
TypeScript プロジェクト全体のコンパイル設定ファイル
①コンパイル設定の定義
②設定ファイルの指定
③方チェックのルール統一
④ビルド関連の設定
tscコマンド実行時はtsconfig.jsonがおかれているディレクトリが基準となる。
実際の設定ファイルの記載例
{
"compilerOptions": {
"jsx": "react",
"target": "ES2020",
"module": "ESNext",
"rootDir": "./src",
"moduleResolution": "node",
"sourceMap": true,
"outDir": "./dist",
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"strict": true,
"baseUrl": "./src",
"paths": {
"utils/*": ["utils/*"]
},
"skipLibCheck": true,
"inlineSources": true
},
"include": ["src/**/*"],
"exclude": ["dist", "node_modules"]
}各種設定値に関する説明
[compilerOptions]
jsx: react
JSX を React 用に変換する設定（React 17 以前想定）
target: ES2020
出力される JavaScript の仕様レベル
module: ESNext
import / export を保持し、バンドラ側で処理する
rootDir: ./src
コンパイル対象のルートディレクトリ
moduleResolution: node
Node.js と同じモジュール解決方法を使用
sourceMap: true
デバッグ用 source map を生成
outDir: ./dist
ビルド成果物の出力先ディレクトリ
esModuleInterop: true
CommonJS モジュールを default import しやすくする
forceConsistentCasingInFileNames: true
import 時の大文字・小文字違いをエラーにする
strict: true
TypeScript の厳密な型チェックをすべて有効化
baseUrl: ./src
絶対パス import の基準ディレクトリ
paths:
utils/* → src/utils/* として解決するエイリアス
skipLibCheck: true
node_modules の型チェックを省略しビルド高速化
inlineSources: true
source map に TypeScript ソースを埋め込む
[include]
コンパイル対象ファイル
React 各UIコンポーネントの記載例
■ラベル
<label className='lbl_Style_1'>大分類</label>■テキストボックス
<input type="text" className='txt_Style_4' value={strTitle} onChange={e => setTitle(e.target.value)} />■ボタン
<button className='flex btnCommonStyle_1 btn_Style_5' onClick={SaveButton_handle}>保存</button>■プルダウン
<const [items1, setItems1] = useState<{ id: string; name: string }[]>([]);
<select
id="item"
className="txt_Style_4"
value={strMajorClassId}
onChange={cmbMajorClass_ChangeValue}
>
<option value=""></option>
{items1.map((item1) => (
<option key={item1.id} value={item1.id}>{item1.name}</option>
))}
</select>■ソースに関して
不明な点はchatgptで調べながら、書いてみました。
既存のソースからコピペすることが多いため、メモとして書いています。
良いか悪いかは別として最近これに依存している割合が高い気がします。
構築している中である程度は理解度が高まってきたような気はしますが、
実際に一からすべて書いてみろと言われたら書けない部分が多い気がします。
プルダウンに関してはDBから表示する項目と項目ごとのIDを取得し、
プルダウンにセットするため、このような書き方となっています。
これだけだとただのメモ書きなので、別記事でプルダウンや
テキストボックスの変数の値の保持の仕方などを書いていこうと思います。
useStateを使った状態管理
画面上に表示、コントロールの設定を行う際の方法に関してのメモとなります。
ページを作成しながらメモを残すようにしておりますが、内容に誤りがある場合もあるため、ご了承ください。
useState(フック)を使った変数の状態管理
useState(フック)
React関数コンポーネント内で状態を管理するための仕組み。
例として画面に表示させるデータの保持やコントロールに対してdisableなどの設定を行うときに使用する。
基本構文
const [state変数,更新用変数] = useState(初期値);
例）名前の情報を画面上で状態管理する場合
function App() {
const [name, setName] = useState('');
① name現在の入力状況を保持する「状態」
② setname 状態を更新する際に使用する関数
nameという変数に対して初期化を行い、setnameで新しい値を更新する。
丸括弧の''は初期値を表す。()と指定した場合はundefinedとして扱われる。
undefinedとして値を渡すとエラーとなる場合も存在するため、
なるべく初期値に関しては明確に定義をすること。
useStateは単純な情報を管理するだけでなくユーザー自身が作成したデータ型を
取り扱うことも可能。
データ型(配列形式ではない変数)を状態管理する場合
const [record, setRecord] = useState
イコール後ろのuseStateの後ろに
XXXXはデータ型の型名となる。
丸括弧部分にはデータ構造内の各初期値を設定するようにする。
複数レコードでは扱わない情報を管理する際に使用する。
下記の記述方法はエラーとなるため、注意。
・丸括弧内の値が''だけ指定している。
({'',''})といった形はエラーが発生する。
データ型(配列形式)を状態管理する場合
const [Tbl, setTbl] = useState
上記の記述に従って記述を行う。
画面上の大量のデータを取り扱う場合には上記のように管理を行う。
単体の変数の更新方法
変数と上書き用の関数の定義例
const [name, setName] = useState('');
上記のように定義されている場合は
setNameが関数となり、この関数を使用して変数nameの更新を行う。
更新する場合は下記のように記述する
setName('B');
上記を記述することで、変数nameの値を値Bとして上書きを行う。
NG例
変数nameに対して直接イコールで変数代入のような記述で更新すれば、良いのでは
ないかとなんとなくで考えがちだが、
name = 'B';
この記述の場合はエラーとなり、データが正しく処理できなくなる。
そのため、上書きをする際は関数経由で更新を行う。
データ型の変数に対して一部の変数のみ更新を行う場合
データ型にデータをセットする場合は下記のように記述する。
const [searchData, setData] = useState
setData({
...searchData,
strMajorClassId: '',
strMiddleClassId: '',
strSmallClassId: ''
});
関数setDataに対してXXXX型のデータ変数内のメンバー変数を書き換える処理。
…XXXXはデータ内の一部を上書きする際に記述する。
※YYYYは初期値を表す。
データ型変数の初期化
データ型変数を初期化する場合はuseStateで設定を行っている初期値自体を関数setDataに渡し、初期化する。
1か所だけソース内で取り扱っている場合は関数に渡す値は直書きで下記のように
記述して処理を行うのも手段としてはありだが、
何度も同じ処理を記述する場合は固定で別に設定用の設定を用意する。
決まった内容で毎度初期化を行うようである場合は下記のように下記の通りに記述する。
const initData: Data = {
strMajorClassId: '',
strMiddleClassId: '',
strSmallClassId: ''
};
初期化を行う際には下記のように記述して初期化を行う
setData(initData);
変数の定義部分で使用する場合は下記のように記述する。
const [searchData, setData] = useState(initData);
とりあえず、基礎的な部分かと思います。
今まで触ってきた言語でフックといった概念がなかったため、はじめ概念を理解するのに
時間がかかりました。追記あれば、また記事でまとめようかと思います。
次は画面の遷移方法に関しての記事がメインとなるかと思います。
今日のところはここまで。
TypeScript 外部ファイルインポート
別ソースファイルを参照したい場合の書き方
◆関数を参照する場合
クラス定義
export default class XXX
関数を呼び出すときはインスタンスを生成して関数を呼び出す。
static関数の場合はクラスから直接参照することが可能。
クラス側でどのように記述するかでimport文の記述が変わる。
export default
①export
記述することで記述したクラスや定数をモジュールとみなし、
外部から参照できるようにする。
②default
import文を記述する際に任意の名称で定義することを可能とする。
◆定数を参照する場合
インポート文
import * as X from './XXX'
参照先の定数の記述
export const AAA = "AAA";
定数の呼び出し文
X.AAA
ほかの書き方だと
import { AAA, BBB } from "./XXX";
上記の場合だとXXX.tsファイルを参照する意味。
拡張子は省略可能。参照ファイルを明確に明示したい場合に使用するべきでしょうか。
後者の書き方は、いちいち定数名を記述しないといけないのは
あまり好きではないので、前者にしています。
Reactを用いたwebシステムの勉強
前回の続き
タイトル通り、reactを用いたwebシステムの勉強を今しております。
以前の記事で社内でのシステムの見直しが図られている中で、
使用環境などがだいぶ明確化されてきたため、今に至る形です。
言語に関してはシステム上でweb版とそれ以外のシステムとで分離するようで、
web版はreact+TypeScript、react+Expressの環境で構築を行っていくようです。
個人的にはちらっと耳にはするけど、いまいちどんなものかはわからないような状態です。
もう一方で完全にオンプレ型のシステムで
C#メインのシステム構築を行っていく方針とのこと。
一時期は言語はJavaでやりましょうとかいや、すべてウェブ系言語でやりましょうなどと
議題が飛び交っていたので、あまり経験がない言語を触れていくのも
どうなるかと思いましたが、慣れている言語で開発ができるのは非常にうれしい限りです。
取り合えず、製品の完成時期が年末になったため、ここから大きく変化することはなさそうです。
データベースも以前まではあまりメジャーではない製品を使用しておりましたが、
MSSQLServerに乗り換える方針とのこと。
以前だと不明点をweb上調べてもメジャーではないデータベースだったため、
得られる情報に限りがあり、また、メーカーに問い合わせをしても結局メーカーの担当者しか
わからない回答ばかりで非常に開発効率と保守性に欠けるものでした。
また、メジャーではないので、「この製品の特化した情報を覚えてもほかで使えないしなあ」というのがあり、
どうにも製品のことを細かく覚えるに至らないなどがありました。
最近の業務でMSSQLに関しては触れていなかったので、これから覚えることはたくさんあるとは
思いますが、メジャーな製品に切り替えてもらえるのは非常にうれしい限りです。
学習に至った背景
いったん社内での開発方針はまとまったものの、将来的にweb言語も触れる可能性は十分にあるため、
タイトルの通り、現在reactの勉強を独自でし始めた限りです。
社内でのweb側は開発担当を選抜されており、リリースするまで自分たちはほとんど触れられないと
判断したので、私は独自で学習をしております。いざ、自分らも開発を行う時に備えての自分なりの対策です。
また、現行のシステムにたいして保守関係の業務が多くなってきており、
個人的に飽きてきた状態です。自分なりにシステムは改修しておりますが、
会社の1つの製品のため、あくまで自分が作成するのは補助ツールくらいのものって感じです。
身に着けることが少なくなってきている中で横で開発チームが自社製品を作成しているのを見ると
このままでいいものかと悩まされてしまうので、そういったことからも新しいことを学習しようと思い、
今に至りました。
とりあえず、Node.jsのインストールから始まり、vscodeのセットアップなどなど時間は
かかっておりますが、進めている段階です。
書くことが多いので、技術的な話は以降の記事で記載するようにします。
6年ぶりの更新
久しぶりのブログ更新となります。
記事の更新をすっかり忘れてしまっておりました。すみません。
今何をしているかと言いますと普通にソフトウェア販売を行なっている会社にてSEをしております。
2019年頃も仕事はしておりましたが、転職済み。別の会社にて勤務をしている状況でございます。
古い言語ですが、保守開発、現場での打ち合わせなどを行なっている毎日です。
最近になりまして会社の事業体制が少しかわり、オンプレ一択のソフト開発から
クラウド中心のシステム開発がメインへと方針が徐々にではありますが、
移り変わってきております。
これまでは古い言語での開発が主だったため、新しい言語や技術を使っていくことをきき、
開発する側としては嬉しい限りではありますが、
新しく言語の勉強やら知識やらを身につけなくてはならないというのが
徐々に実感が出てきて自分でも何か勉強はしなくてはと思っている次第です。
言語の選定を行なっている段階のため、個人的には知っている技術で
クラウドの理解を深めたいとは思いますが、割と新しめの言語にも触れたいというのが本音ではあります。
仕様を決めるのは私ではないため、早く決めて欲しいものです。
ブログについて。
しばらく更新が止まっており、過去の記事でこんな記事書いたっけとだいぶ記憶から
薄れている状態ではありますが、自分の備忘録という意味でも
ブログの更新を再開しようかと考えております。
やる気が無くならないうちに次回の記事を更新をしようと思いますため、
よろしくお願いします。
