並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 22 件 / 22件

新着順 人気順

typescriptの検索結果1 - 22 件 / 22件

  • 【2024年最新版】0からReactを勉強するならこのロードマップに従え! - Qiita

    はじめに こんにちは@Sicut_study (Watanabe Jin)です。 去年の10月頃にReactのロードマップを投稿しておかげさまで1000いいねもすぐそこになりました そこから私自身も状況がかなり変わり、大好きなReactを使ってプログラミングを教えるスクールを運営しております。 エンジニアになりたい完全未経験の方や、すでにエンジニアだけどもっと自由にプログラミングができるようになりたい人をたくさん教えてきました。 👇メンバーの記事はこちらにあります その中である程度この流れで学習をすすめていけば1-2ヶ月程度でReactで自由にサービスを作れるレベルに再現性をもってレベルアップすることができると確信がもてたので、 実際にやっているカリキュラム(React部分)をすべて紹介します ロードマップは完全未経験でもできるようなものになっていますのでわかる箇所は飛ばしてもOKです。

      【2024年最新版】0からReactを勉強するならこのロードマップに従え! - Qiita
    • 2024年のRailsと自由について考える

      えにしテック15周年記念カンファレンスの発表資料です。 https://enishi-tech-15th-anniv-conf.peatix.com/ 資料中で参照しているURLは以下です: https://github.com/rails/rails/milestone/87 https:…

        2024年のRailsと自由について考える
      • 『Rustで作るプログラミング言語』を読んで、かねてから構想していた自作言語を形にした - Islands in the byte stream

        Rustで作るプログラミング言語という書籍が先日発売されました。簡単なプログラミング言語を作ってバイトコードに変換して実行したりネイティブコードに変換して実行してみよう、という本で、大変面白く読みました。最終的にまあまあ本格的な言語になるので、これを元にするとわりとちゃんとした言語を作れそうです。 この書籍で最終的に作られる言語はこちら: GitHub - msakuta/ruscal: Programming language implementation learning project ちょうど私も、以前から構想していた言語があったので、ちょっと作ってみました。というのも、TypeScriptを設定記述言語としてさまざまなプログラミング言語から使えると便利ではないかとずっと思っていたのです。 この設定言語で複雑なことができる必要はなく、最終的にはJSONに準ずるデータ構造になればよい

          『Rustで作るプログラミング言語』を読んで、かねてから構想していた自作言語を形にした - Islands in the byte stream
        • 【T3 Stack】フロントエンド・バックエンドTypescript開発入門

          はじめに フロントエンドもバックエンドもTypescriptで書きたい!ということで、T3 Stack(T3スタック)について調べてみました。 T3 Stackを利用したプロジェクトを作成するためのCLIツールcreate-t3-appが用意されており、簡単に雛形プロジェクトが作れるため、実際に使ってみました。 この記事は以下の内容をメインに紹介します。 create-t3-appの環境構築手順 雛形プロジェクトの解説(特にtRPCを用いたAPIの呼び出し方法について) T3 Stackとは T3 Stackとはsimplicity(簡潔さ)、modularity(モジュール性)、full-stack type safety(フルスタックの型安全)を追求した思想に焦点を当てています。 そしてそれらを実現するために以下6つの技術スタックが採用されています。 ✅ Next.js ✅ tRPC

            【T3 Stack】フロントエンド・バックエンドTypescript開発入門
          • Node.jsでTypeScriptのコードを実行できるようになるかも - hiroppy's site

            module: add --experimental-strip-types by marco-ippolito · Pull Request #53725 · nodejs/node It is possible to execute TypeScript files by setting the experimental flag --experimental-strip-typ... 💁‍♀️ まだマージされてない点に注意してください --experimental-strip-typesというフラグを実行時に付けることにより、Node.jsでTypeScriptのコードを実行できるようになるPRが出てきました。 背景 TC39でも型注釈の話題(議事録を読むとブラウザとの兼ね合いもあり道のりは長そう)が存在するほどJSのコードにおいて、型は当たり前となっています。 Node.jsと同

              Node.jsでTypeScriptのコードを実行できるようになるかも - hiroppy's site
            • [K, U] extends [U, K] ← ナニコレ

              タイトルは初見時の自分の気持ちでした。内容は結構あっさりしたもので、5分あれば読めると思います。 「あーなるほどね」となった方はわざわざ読む必要がない記事っぽいです。 型の互換性チェック 一言で言ってしまえばそういうことです。KとUが互いに置き換え可能かどうかを確認しています。 これがKとUのままだと分かりづらいのですが、適当な型に置き換えてみると分かりやすいです。 type Test1 = [1, 1] extends [1, 1] ? true : false; // true type Test2 = [number, number] extends [number, number] ? true : false; // true type Test3 = [string, string] extends [string, string] ? true : false; // tru

                [K, U] extends [U, K] ← ナニコレ
              • TypeSpec、Orval、Storybook を使ってフロントエンドのモック生成を自動化する

                はじめに フロントエンド開発において、効率的かつ一貫性のあるモック生成は非常に重要です。本記事では TypeSpec、Orval、Storybook の 3 つのツールを使用して自動生成でモックを実現する方法を紹介します。 TypeSpec は、大規模な API を提供するために Microsoft が開発し、使用している新しい API 記述言語です。 Orval は、OpenAPI 仕様から TypeScript のクライアントコードを生成するツールです。これにより、最新の API 仕様に基づいたクライアントコードを常に保持し、API との通信がスムーズに行えるようになります。 Storybook は、コンポーネントを独立して開発・テストするためのインタラクティブなツールです。コンポーネントの見た目や動作を個別に確認できるため、UI の一貫性を保ちながら効率的に開発を進めることができます

                  TypeSpec、Orval、Storybook を使ってフロントエンドのモック生成を自動化する
                • .tsファイルを直接実行するのにtsxで特に困っていない | Marginalia

                  Node.js 本体で TypeScript ファイルを実行できるようにするプロポーザルが出されているという話が先週あたりから話題になっている。しかしそれほど嬉しいかといわれると、正直いらんなあと思っている。 TypeScriptで簡単なスクリプトを書くときは、長らくtsxを使って実行している。tsxを使い始めるより前は ts-node を使っていたが、tsxを使ってからは何の不満もなく使い続けている。 tsxは内部的にはesbuildでTypeScriptをトランスパイルしていて、型チェックは行わない。tsxのありがたい点は、すべての node コマンドのオプションを tsx コマンドでサポートしていることだ。単純にコマンドを置き換えるだけでいいので、何も新しく覚えることがない。 構造的にはNode.jsの中でswcでJavaScriptに変換されるか、外でesbuildで変換されるかの

                    .tsファイルを直接実行するのにtsxで特に困っていない | Marginalia
                  • Modern Emacs Typescript Web (React) Config with lsp-mode, treesitter, tailwind, TSX & more - Ovi Stoica

                    Table of Contents Introduction Part 1: Treesitter for Typescript & TSX LSP Support Completion setup Linter setup LSP Setup Eslint (Optional) Tailwind LSP Server LSP Performance Emacs LSP Booster Structural editing Formatting buffers with Prettier Other resources Conclusion Introduction I've worked within the JS ecosystem for the past 8 years using editors like Webstorm and VSCode, I started using

                    • Next.jsで不要なファイルを一掃する

                      Knipというツールが便利。JaveScriptやTypeScriptで書かれているプロジェクトの未使用のファイルやexportを見つけることができる。 Find unused files, dependencies and exports in JavaScript and TypeScript projects https://knip.dev/ インストールせずに使いたいのでnpxコマンドを使って実行する。 また、Next.jsのプロジェクトで使いたいのでプラグインを導入する。 上記のプラグインの中にNext.jsがあるのでこれを使う。 knip.jsonというファイルをプロジェクトのルートに配置する。除外したいディレクトリはignoreで指定できる。 { "ignore": [ "hoge" ], "next": { "entry": [ "next.config.{js,ts,c

                        Next.jsで不要なファイルを一掃する
                      • OpenAPI TypeScript

                        OpenAPI TypeScriptConvert OpenAPI 3.0/3.1 schemas to TypeScript types and create type-safe fetching.

                        • Object.groupBy で作られるオブジェクトの prototype は null - Object.create(null)

                          おさらい: prototype JavaScript のオブジェクトはみんな prototype というのを持っていて, この prototype からプロパティを継承, より正確には, プロパティアクセス時にそのプロパティがオブジェクトに存在しなければ prototype を辿って見つけにいくことになっている. あるオブジェクトを prototype とした別のオブジェクトを作るには Object.create を使う (あるいは new 演算子や __proto__ を使っても良い). const x = {}; x.foo = "foo"; const y = Object.create(x); y.bar = "bar"; const z = Object.create(y); z.baz = "baz"; console.log(z.foo); // => "foo" conso

                            Object.groupBy で作られるオブジェクトの prototype は null - Object.create(null)
                          • What's coming next for ESLint - ESLint - Pluggable JavaScript Linter

                            When we released ESLint v9.0.0 in April, it was the first major release in 30 months and formally introduced the new configuration system. ESLint v9.0.0 also made some rule API changes to prepare the core for what’s coming next. After the release, we spent a lot of time creating compatibility utilities, a configuration migration tool, and a rule API transform utility to help the ecosystem move to

                              What's coming next for ESLint - ESLint - Pluggable JavaScript Linter
                            • Bun の非互換な拡張 API - moriken's project

                              Bun は WinterCG meetings に参加せず、標準から外れた拡張を利便性のために結構取り入れている。またエコシステムとして合意の取れていない実装をすることもある。これら API を使ってしまうと Node.js や Deno、Cloudflare Workers などで扱えず相互運用性の問題となる。知らず知らずのうちに使ってしまわないようにまとめておく。 Jarred Sumner @jarredsumner 2024/02/18 02:45 JS runtimes obsess about web standards but web standards orgs are incentivized to only care about browsers Luca Casonato 🏳️‍🌈 @lcasdev 2024/02/18 05:48 @jarredsumner J

                                Bun の非互換な拡張 API - moriken's project
                              • TypeScript 5.5で導入されたisolatedDeclarationsは、JavaScriptエコシステムを大きく変えるゲームチェンジャーかもしれない

                                7月7日、Denoの開発者マーヴィン・H氏が「JavaScriptエコシステムを加速する(Speeding up the JavaScript ecosystem)」と題した記事を公開した。この記事では、TypeScriptの新機能「isolatedDeclaration」が、JavaScript / TypeScriptエコシステムを変革する可能性について詳細に紹介されている。本記事ではその内容を簡単に紹介する。 本記事は、以下のエキスパートの皆様に監修していただきました: 古川陽介さん(Japan Node.js Association代表理事) うひょさん(株式会社カオナビ フロントエンドエンジニア) npmパッケージングの問題点 現在npmでのパッケージングプロセスは相当に複雑である。モジュールをnpmに公開しようとする開発者は、CommonJS対ESMの問題や、多くの設定調整を行

                                  TypeScript 5.5で導入されたisolatedDeclarationsは、JavaScriptエコシステムを大きく変えるゲームチェンジャーかもしれない
                                • GitHub - webpod/graphql-megaera: GraphQL to TypeScript Generator

                                  You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                    GitHub - webpod/graphql-megaera: GraphQL to TypeScript Generator
                                  • Support typescript with --experimental-strip-types · Issue #208 · nodejs/loaders

                                    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                      Support typescript with --experimental-strip-types · Issue #208 · nodejs/loaders
                                    • Web サービスをフロントもバックも TypeScript で作る時の構成例

                                      せっかくなのでフロントもバックも TypeScript を使おう、ということで、アレコレ考えて作った構成を共有します。何かの参考になれば幸いです。 下記の Web サービスを開発するときに使いました。 システム構成 ランタイム:Bun フレームワーク: Express ORM:Drizzle ORM インフラ:Docker 私的にはバックエンド中心で処理・出力し、そのうえでフロントエンドを使うのが好きです。 ディレクトリ・ファイル構成の例 あまり深くディレクトリを掘りたくなかったので、ルートに散在しています。 ├── assets :ビルドされたフロントエンドのファイルが入る ├── constants :定数関係 │   └── index.ts ├── controllers ;コントローラー │   ├── _Controller.ts:ルート(/)のコントローラー │   └──

                                        Web サービスをフロントもバックも TypeScript で作る時の構成例
                                      • Next.jsとHono RPCで安全・爆速開発

                                        AVベースはNext.js(Pages Router)のモノリスで作っています。画面から呼び出すAPIには Next.js の API Routes を使っています。API RoutesはHTTPメソッドを自分でハンドルする必要があったり、エラーハンドリングを各ファイルごとに行う必要があったりと、そのまま使うにはあまり便利ではありません。 そこでAPI RoutesでHonoを使うことにしました。Honoは高速かつ様々なランタイムで動作することで人気ですが、型推論を利用した RPC 機能も搭載しています。RPCによってサーバー・クライアント間の型が接続されたことで、画像のような快適な開発が可能になりました 左がサーバー側、右がクライアント側のコード。サーバー側のリファクタリングがクライアントにも反映される様子(リクエスト・レスポンスともに message というフィールドを text に置

                                          Next.jsとHono RPCで安全・爆速開発
                                        • ディレクトリ単位でTypeScriptの自動補完を制御する

                                          前提条件 TypeScriptを使用している package.jsonは1つのみ 今回対象とするディレクトリのルートにpackage.jsonがあり、それより子のディレクトリにはpackage.jsonがない モノレポではなくモノリスのイメージ。モノレポであれば恐らくworkspaceを切る方が何かと素直になりそう 試した環境 Visual Studio Code version 1.91(2024年7月7日頃の最新バージョン) やりたいこと ディレクトリ毎に依存方向を決めている場合等に、依存してはいけないディレクトリの関数や変数が自動補完の対象となるのを防ぎたい 今回検証するリポジトリの構成 ルートディレクトリにpackage.jsonとtsconfig.jsonがある(ここは通常通り) srcの直下にはconstants, utils, featuresというディレクトリがある fea

                                            ディレクトリ単位でTypeScriptの自動補完を制御する
                                          • GitHub - mjackson/fetch-super-headers: A drop-in replacement for JavaScript `Headers` with type-safe access

                                            You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                              GitHub - mjackson/fetch-super-headers: A drop-in replacement for JavaScript `Headers` with type-safe access
                                            • JSON.parse(JSON.stringify(x))に型をつけよう

                                              はじめに WebバックエンドとクライアントをともにTypeScriptで書くとします。また、バックエンドではJSON.stringifyで値をシリアライズし、クライアントサイドではJSON.parse相当の処理でレスポンスボディを取得すると仮定しましょう[1]。このとき、JSON.stringifyの挙動がわかれば、実際にクライアントにどのような値が返ってきうるかを型で表現できるはずです。例えば、 となるので、{ a: undefined }の型をJSON.stringifyしてからJSON.parseした値の型は{}とするべきです。 本稿では、JSON.stringifyの仕様に沿ってそのような型を定義する方法について解説していきます。また、その際の制限についても最後に軽く触れます。 背景 本稿の概要を理解をするためには不要ですが、この節ではそれを試みることになった背景についてお話ししま

                                                JSON.parse(JSON.stringify(x))に型をつけよう
                                              1