Dang  Tu

Dang Tu

1657786420

Cách Chạy Mã VS Với OpenShift Dev Spaces

Red Hat OpenShift Dev Spaces là một máy chủ môi trường dành cho nhà phát triển OpenShift -native. Phiên bản 3.0 vừa được phát hànhnó cho phép bạn chọn IDE sẽ được đưa vào môi trường phát triển . Hiện tại, các trình soạn thảo đi kèm với OpenShift Dev Spaces là Eclipse TheiaJetBrains IntelliJ IDEA .

Điều gì về Visual Studio Code? Mặc dù chúng tôi dự định sử dụng nó làm IDE mặc định trong các phiên bản tương lai của OpenShift Dev Spaces, nhưng Visual Studio Code không được bao gồm trong phiên bản 3.0. Nhưng Eclipse Che , là dự án ngược dòng cho OpenShift Dev Spaces, đã bao gồm nó và chúng ta cũng có thể dễ dàng sử dụng nó trong OpenShift Dev Spaces. Đọc tiếp để tìm hiểu cách hoạt động của nó.

Chọn Visual Studio Code làm trình chỉnh sửa môi trường Dev Space

Visual Studio Code được bao gồm trong sổ đăng ký plugin Eclipse Che với số nhận dạng che-incubator/che-code/insiders. OpenShift Dev Spaces có sổ đăng ký plugin nội bộ của riêng mình, nhưng nó cũng có thể sử dụng các đăng ký bên ngoài, bao gồm cả sổ đăng ký plugin Eclipse Che trực tuyến . Chúng tôi có thể tham khảo sổ đăng ký Che trực tuyến bằng cách sử dụng tệp trong kho lưu trữ Git hoặc thông qua tham số URL. Chúng tôi sẽ xem xét nhanh từng cách tiếp cận.

Tùy chọn 1: Thêm che-editor.yaml vào kho lưu trữ Git

Cách dễ nhất để sử dụng Visual Studio Code cho một dự án nhất định là tham chiếu nó từ một che-editor.yamltệp trong kho lưu trữ Git.

Tạo một .chethư mục và thêm một che-editor.yamltệp có nội dung sau:

id: che-incubator/che-code/insiders
registryUrl: https://eclipse-che.github.io/che-plugin-registry/main/v3

Dòng đầu tiên chỉ định định danh của trình soạn thảo. Dòng thứ hai chứa URL của sổ đăng ký plugin nơi trình chỉnh sửa được xuất bản. Chúng tôi đang sử dụng sổ đăng ký plugin Eclipse Che trực tuyến trong ví dụ này.

Chỉ cần cam kết và đẩy thay đổi vào kho lưu trữ Git của dự án (Hình 1). Khi tệp được đẩy, bất kỳ môi trường phát triển từ xa OpenShift Dev Spaces nào bắt đầu sử dụng URL kho lưu trữ Git (GitHub, GitLab và Bitbucket được hỗ trợ) sẽ sử dụng Visual Studio Code làm trình chỉnh sửa.

Thêm tệp .che / che-editor.yaml vào kho lưu trữ git

Hình 1: Thêm tệp .che / che-editor.yaml vào kho lưu trữ Git

Visual Studio Code không phải là trình chỉnh sửa duy nhất có thể được sử dụng từ sổ đăng ký plugin Che trực tuyến. Dưới đây là danh sách các ID trình chỉnh sửa có thể được tham chiếu từ .che/che-editor.yaml:

Biên tập viênID người chỉnh sửa trong sổ đăng ký plugin Che
Mã Visual Studioche-incubator/che-code/insiders
JetBrains IntelliJ IDEA

che-incubator/che-idea/next

che-incubator/che-idea/latest

JetBrains PyCharm

che-incubator/che-pycharm/next

che-incubator/che-pycharm/latest

Tùy chọn 2: Sử dụng tham số URL che-editor

Không phải lúc nào bạn cũng có thể thêm tệp .che/che-editor.yamlvào kho lưu trữ Git. Trong những trường hợp này, vẫn có thể chỉ định trình chỉnh sửa bằng cách sử dụng che-editortham số URL:

https://<devspaces-hostname>#<git-repository-url>?che-editor=<editor-definition-url>

Đây là một ví dụ về một URL như vậy:

https://devspaces.apps.mloriedo-devworkspaces.devcluster.openshift.com/#https://github.com/devfile/api?che-editor=https://eclipse-che.github.io/che-plugin-registry/main/v3/plugins/che-incubator/che-code/insiders/devfile.yaml

Sử dụng tham số URL che-editor

Hình 2: Sử dụng tham số URL che-editor

Dưới đây là danh sách các định nghĩa trình chỉnh sửa có sẵn trong sổ đăng ký plugin Che có thể được sử dụng trong che-editortham số URL:

Biên tập viênLiên kết đến định nghĩa Che Plugin Registry
Mã Visual Studiodevfile.yaml
JetBrains IntelliJ IDEA

devfile.yaml (phiên bản mới nhất)

devfile.yaml (phiên bản mới nhất tiếp theo)

JetBrains PyCharm

devfile.yaml (phiên bản mới nhất)

devfile.yaml (phiên bản mới nhất tiếp theo)

Có những phần mở rộng Visual Studio Code nào?

Mã nhị phân Visual Studio Code có trong sổ đăng ký plugin Che được cấu hình trước để sử dụng Đăng ký VSX mở trực tuyến , chứa hàng nghìn tiện ích mở rộng và thuộc sở hữu của Eclipse Foundation. Những phần mở rộng đó có thể được cài đặt từ chính Visual Studio Code như bình thường (Hình 3).

Duyệt và cài đặt tiện ích mở rộng Visual Studio Code từ Open VSX

Hình 3: Duyệt và cài đặt tiện ích mở rộng Visual Studio Code từ Open VSX

Việc sử dụng tiện ích mở rộng VSX mở trong các trường hợp không khí hiện không được hỗ trợ. Chúng tôi đang làm việc trên một phiên bản ngoại tuyến của Open VSX Registry có thể được sử dụng với OpenShift Dev Spaces để hỗ trợ những môi trường như vậy, nhưng phiên bản đó sẽ không khả dụng trước OpenShift Dev Spaces 3.3.

Mã Visual Studio có được hỗ trợ cho OpenShift Dev Spaces không?

Visual Studio Code hiện chỉ là một dự án cộng đồng và do đó, nó không được bao gồm trong bộ phận hỗ trợ khách hàng của OpenShift Dev Spaces. (Phần còn lại của môi trường OpenShift Dev Spaces của bạn được hỗ trợ đầy đủ; chỉ trình chỉnh sửa đã thay đổi sẽ không được hỗ trợ đầy đủ nếu bạn cài đặt nó.) Đối với thay đổi này, Red Hat sẽ cung cấp hỗ trợ "hợp lý về mặt thương mại", có nghĩa là chúng tôi sẽ cố gắng giúp bạn nhưng không thể đảm bảo tương tự (với SLA) mà chúng tôi thực hiện cho phần còn lại của OpenShift Dev Spaces.

Sự khác biệt giữa trình soạn thảo này và Microsoft Visual Studio Code là gì?

Trình soạn thảo dựa trên Visual Studio Code được Eclipse Che sử dụng, được gọi là che-code , là một tùy chỉnh của Visual Studio Code Open Source (Code OSS). Nó không phải là một nhánh của Code OSS (mã nguồn được bao gồm dưới dạng cây con Git ) và điều đó giúp bạn dễ dàng tự động tìm nạp những thay đổi mới nhất từ ​​Code OSS nhiều lần một ngày (hiện tại là bốn giờ một lần).

Các che-codetùy chỉnh bao gồm:

  • Biểu tượng và nhãn Eclipse Che (thương hiệu)
  • Một số tiện ích mở rộng tích hợp bổ sung (giám sát tài nguyên, plugin cổng, lệnh devfile, dự án và hỗ trợ thiết bị đầu cuối từ xa)
  • Cấu hình để sử dụng Open VSX Registry trực tuyến
  • Chọn không tham gia tính năng đo từ xa của Microsoft

Microsoft Visual Studio Code cũng được xây dựng dựa trên Code OSS, nhưng bao gồm một số tiện ích mở rộng tích hợp sẵn mã nguồn đóng, sử dụng thị trường tiện ích mở rộng Microsoft Visual Studio Code và đã bật tính năng đo từ xa.

Chúng tôi đã xem xét sử dụng một dự án hiện có như coder hoặc openvscode-server để chạy Visual Studio Code trong trình duyệt. Nhưng đó là những fork (khiến chúng khó rebase hơn) và mã để chạy Visual Studio Code trong trình duyệt, tính đến thời điểm hiện tại, là mã nguồn mở và có sẵn trong Code OSS, vì vậy chúng tôi không nghĩ rằng hiện tại có bất kỳ giá trị nào để sử dụng một dự án trung gian.

Lộ trình đưa Mã Visual Studio vào OpenShift Dev Spaces là gì?

Trình soạn thảo OpenShift Dev Spaces mặc định vẫn là Eclipse Theia, nhưng số lượng phần mở rộng Visual Studio Code có thể được Theia chạy đúng cách bị hạn chế. Đó là vấn đề chính của chúng tôi trong ba năm qua. Các nhà phát triển không quan tâm nhiều đến câu hỏi của Visual Studio Code so với Eclipse Theia, nhưng họ muốn chạy vô số các tiện ích mở rộng có sẵn trên mạng.

Mục tiêu chính của chúng tôi cho Q3 2022 là bao gồm trình soạn thảo dựa trên Code OSS sử dụng Open VSX Registry trong OpenShift Dev Spaces và đặt nó làm trình chỉnh sửa mặc định. Để làm được điều đó, chúng tôi hiện đang thu hẹp khoảng cách về tính năng với Theia. Đặc biệt, chúng tôi đang nghiên cứu cơ chế chạy không tải để dừng các môi trường không hoạt động trong một khoảng thời gian nhất định, cũng như nghiên cứu hỗ trợ cho các môi trường có không khí.

Có thể sử dụng Mã Visual Studio trên Hộp cát dành cho nhà phát triển không?

Red Hat Developer Sandbox chưa được cập nhật lên OpenShift Dev Spaces và không thể sử dụng CodeReady Workspaces 2.15 để cung cấp môi trường phát triển dựa trên Visual Studio Code . Nhưng DevWorkspace Operator, công cụ môi trường dành cho nhà phát triển mới được OpenShift Dev Spaces sử dụng, được cài đặt trên Developer Sandbox (vì Web Terminal phụ thuộc vào nó) và nó hỗ trợ chạy môi trường phát triển dựa trên Visual Studio Code.

Dưới đây là một số hướng dẫn dòng lệnh để thực hiện điều đó từ OpenShift Web Terminal. Bạn có thể xem kết quả trong Hình 4.

VSCODE_SAMPLE_DW="https://eclipse-che.github.io/che-devfile-registry/main/devfiles/nodejs/devworkspace-che-code-insiders.yaml"
 
curl  -sSL "${VSCODE_SAMPLE_DW}" | sed 's/^[[:space:]]\{8,\}container:/        container:^          env: [{name: CODE_HOST, value: "0.0.0.0"}]/g' | # <-- CHE IS NOT THERE
sed 's/template:/template:^    attributes:^      controller.devfile.io\/storage-type: ephemeral/g' | # <-- EPHEMERAL IS FASTER
sed 's/volume: {}/volume: {ephemeral: true}/g' |
sed '/tkn=eclipse-che/d' |
tr '^' '\n' | \
oc apply -f -
oc get dw nodejs-web-app --watch

Chạy mã Visual Studio trong Red Hat Developer Sandbox bằng DevWorkspace Operator

Hình 4: Chạy Visual Studio Code trong Red Hat Developer Sandbox bằng DevWorkspace Operator

Chúng tôi vẫn đang nỗ lực mở rộng hỗ trợ trình chỉnh sửa trong OpenShift Dev Spaces. Nhưng bằng cách làm theo các bước được nêu ở đây, người dùng có thể tận dụng sự quen thuộc của họ với Visual Studio Code và hệ sinh thái các tiện ích mở rộng của nó ngay hôm nay.

Đặc biệt cảm ơn Rick Wagner và Florent Benoit đã đánh giá và góp ý cho bài viết này.

Liên kết: https://developers.redhat.com/articles/2022/07/12/how-run-vs-code-openshift-dev-spaces#is_it_possible_to_use_visual_studio_code_on_the_developer_sandbox_

#visualstudiocode #openshift 

What is GEEK

Buddha Community

Cách Chạy Mã VS Với OpenShift Dev Spaces
Dang  Tu

Dang Tu

1657786420

Cách Chạy Mã VS Với OpenShift Dev Spaces

Red Hat OpenShift Dev Spaces là một máy chủ môi trường dành cho nhà phát triển OpenShift -native. Phiên bản 3.0 vừa được phát hànhnó cho phép bạn chọn IDE sẽ được đưa vào môi trường phát triển . Hiện tại, các trình soạn thảo đi kèm với OpenShift Dev Spaces là Eclipse TheiaJetBrains IntelliJ IDEA .

Điều gì về Visual Studio Code? Mặc dù chúng tôi dự định sử dụng nó làm IDE mặc định trong các phiên bản tương lai của OpenShift Dev Spaces, nhưng Visual Studio Code không được bao gồm trong phiên bản 3.0. Nhưng Eclipse Che , là dự án ngược dòng cho OpenShift Dev Spaces, đã bao gồm nó và chúng ta cũng có thể dễ dàng sử dụng nó trong OpenShift Dev Spaces. Đọc tiếp để tìm hiểu cách hoạt động của nó.

Chọn Visual Studio Code làm trình chỉnh sửa môi trường Dev Space

Visual Studio Code được bao gồm trong sổ đăng ký plugin Eclipse Che với số nhận dạng che-incubator/che-code/insiders. OpenShift Dev Spaces có sổ đăng ký plugin nội bộ của riêng mình, nhưng nó cũng có thể sử dụng các đăng ký bên ngoài, bao gồm cả sổ đăng ký plugin Eclipse Che trực tuyến . Chúng tôi có thể tham khảo sổ đăng ký Che trực tuyến bằng cách sử dụng tệp trong kho lưu trữ Git hoặc thông qua tham số URL. Chúng tôi sẽ xem xét nhanh từng cách tiếp cận.

Tùy chọn 1: Thêm che-editor.yaml vào kho lưu trữ Git

Cách dễ nhất để sử dụng Visual Studio Code cho một dự án nhất định là tham chiếu nó từ một che-editor.yamltệp trong kho lưu trữ Git.

Tạo một .chethư mục và thêm một che-editor.yamltệp có nội dung sau:

id: che-incubator/che-code/insiders
registryUrl: https://eclipse-che.github.io/che-plugin-registry/main/v3

Dòng đầu tiên chỉ định định danh của trình soạn thảo. Dòng thứ hai chứa URL của sổ đăng ký plugin nơi trình chỉnh sửa được xuất bản. Chúng tôi đang sử dụng sổ đăng ký plugin Eclipse Che trực tuyến trong ví dụ này.

Chỉ cần cam kết và đẩy thay đổi vào kho lưu trữ Git của dự án (Hình 1). Khi tệp được đẩy, bất kỳ môi trường phát triển từ xa OpenShift Dev Spaces nào bắt đầu sử dụng URL kho lưu trữ Git (GitHub, GitLab và Bitbucket được hỗ trợ) sẽ sử dụng Visual Studio Code làm trình chỉnh sửa.

Thêm tệp .che / che-editor.yaml vào kho lưu trữ git

Hình 1: Thêm tệp .che / che-editor.yaml vào kho lưu trữ Git

Visual Studio Code không phải là trình chỉnh sửa duy nhất có thể được sử dụng từ sổ đăng ký plugin Che trực tuyến. Dưới đây là danh sách các ID trình chỉnh sửa có thể được tham chiếu từ .che/che-editor.yaml:

Biên tập viênID người chỉnh sửa trong sổ đăng ký plugin Che
Mã Visual Studioche-incubator/che-code/insiders
JetBrains IntelliJ IDEA

che-incubator/che-idea/next

che-incubator/che-idea/latest

JetBrains PyCharm

che-incubator/che-pycharm/next

che-incubator/che-pycharm/latest

Tùy chọn 2: Sử dụng tham số URL che-editor

Không phải lúc nào bạn cũng có thể thêm tệp .che/che-editor.yamlvào kho lưu trữ Git. Trong những trường hợp này, vẫn có thể chỉ định trình chỉnh sửa bằng cách sử dụng che-editortham số URL:

https://<devspaces-hostname>#<git-repository-url>?che-editor=<editor-definition-url>

Đây là một ví dụ về một URL như vậy:

https://devspaces.apps.mloriedo-devworkspaces.devcluster.openshift.com/#https://github.com/devfile/api?che-editor=https://eclipse-che.github.io/che-plugin-registry/main/v3/plugins/che-incubator/che-code/insiders/devfile.yaml

Sử dụng tham số URL che-editor

Hình 2: Sử dụng tham số URL che-editor

Dưới đây là danh sách các định nghĩa trình chỉnh sửa có sẵn trong sổ đăng ký plugin Che có thể được sử dụng trong che-editortham số URL:

Biên tập viênLiên kết đến định nghĩa Che Plugin Registry
Mã Visual Studiodevfile.yaml
JetBrains IntelliJ IDEA

devfile.yaml (phiên bản mới nhất)

devfile.yaml (phiên bản mới nhất tiếp theo)

JetBrains PyCharm

devfile.yaml (phiên bản mới nhất)

devfile.yaml (phiên bản mới nhất tiếp theo)

Có những phần mở rộng Visual Studio Code nào?

Mã nhị phân Visual Studio Code có trong sổ đăng ký plugin Che được cấu hình trước để sử dụng Đăng ký VSX mở trực tuyến , chứa hàng nghìn tiện ích mở rộng và thuộc sở hữu của Eclipse Foundation. Những phần mở rộng đó có thể được cài đặt từ chính Visual Studio Code như bình thường (Hình 3).

Duyệt và cài đặt tiện ích mở rộng Visual Studio Code từ Open VSX

Hình 3: Duyệt và cài đặt tiện ích mở rộng Visual Studio Code từ Open VSX

Việc sử dụng tiện ích mở rộng VSX mở trong các trường hợp không khí hiện không được hỗ trợ. Chúng tôi đang làm việc trên một phiên bản ngoại tuyến của Open VSX Registry có thể được sử dụng với OpenShift Dev Spaces để hỗ trợ những môi trường như vậy, nhưng phiên bản đó sẽ không khả dụng trước OpenShift Dev Spaces 3.3.

Mã Visual Studio có được hỗ trợ cho OpenShift Dev Spaces không?

Visual Studio Code hiện chỉ là một dự án cộng đồng và do đó, nó không được bao gồm trong bộ phận hỗ trợ khách hàng của OpenShift Dev Spaces. (Phần còn lại của môi trường OpenShift Dev Spaces của bạn được hỗ trợ đầy đủ; chỉ trình chỉnh sửa đã thay đổi sẽ không được hỗ trợ đầy đủ nếu bạn cài đặt nó.) Đối với thay đổi này, Red Hat sẽ cung cấp hỗ trợ "hợp lý về mặt thương mại", có nghĩa là chúng tôi sẽ cố gắng giúp bạn nhưng không thể đảm bảo tương tự (với SLA) mà chúng tôi thực hiện cho phần còn lại của OpenShift Dev Spaces.

Sự khác biệt giữa trình soạn thảo này và Microsoft Visual Studio Code là gì?

Trình soạn thảo dựa trên Visual Studio Code được Eclipse Che sử dụng, được gọi là che-code , là một tùy chỉnh của Visual Studio Code Open Source (Code OSS). Nó không phải là một nhánh của Code OSS (mã nguồn được bao gồm dưới dạng cây con Git ) và điều đó giúp bạn dễ dàng tự động tìm nạp những thay đổi mới nhất từ ​​Code OSS nhiều lần một ngày (hiện tại là bốn giờ một lần).

Các che-codetùy chỉnh bao gồm:

  • Biểu tượng và nhãn Eclipse Che (thương hiệu)
  • Một số tiện ích mở rộng tích hợp bổ sung (giám sát tài nguyên, plugin cổng, lệnh devfile, dự án và hỗ trợ thiết bị đầu cuối từ xa)
  • Cấu hình để sử dụng Open VSX Registry trực tuyến
  • Chọn không tham gia tính năng đo từ xa của Microsoft

Microsoft Visual Studio Code cũng được xây dựng dựa trên Code OSS, nhưng bao gồm một số tiện ích mở rộng tích hợp sẵn mã nguồn đóng, sử dụng thị trường tiện ích mở rộng Microsoft Visual Studio Code và đã bật tính năng đo từ xa.

Chúng tôi đã xem xét sử dụng một dự án hiện có như coder hoặc openvscode-server để chạy Visual Studio Code trong trình duyệt. Nhưng đó là những fork (khiến chúng khó rebase hơn) và mã để chạy Visual Studio Code trong trình duyệt, tính đến thời điểm hiện tại, là mã nguồn mở và có sẵn trong Code OSS, vì vậy chúng tôi không nghĩ rằng hiện tại có bất kỳ giá trị nào để sử dụng một dự án trung gian.

Lộ trình đưa Mã Visual Studio vào OpenShift Dev Spaces là gì?

Trình soạn thảo OpenShift Dev Spaces mặc định vẫn là Eclipse Theia, nhưng số lượng phần mở rộng Visual Studio Code có thể được Theia chạy đúng cách bị hạn chế. Đó là vấn đề chính của chúng tôi trong ba năm qua. Các nhà phát triển không quan tâm nhiều đến câu hỏi của Visual Studio Code so với Eclipse Theia, nhưng họ muốn chạy vô số các tiện ích mở rộng có sẵn trên mạng.

Mục tiêu chính của chúng tôi cho Q3 2022 là bao gồm trình soạn thảo dựa trên Code OSS sử dụng Open VSX Registry trong OpenShift Dev Spaces và đặt nó làm trình chỉnh sửa mặc định. Để làm được điều đó, chúng tôi hiện đang thu hẹp khoảng cách về tính năng với Theia. Đặc biệt, chúng tôi đang nghiên cứu cơ chế chạy không tải để dừng các môi trường không hoạt động trong một khoảng thời gian nhất định, cũng như nghiên cứu hỗ trợ cho các môi trường có không khí.

Có thể sử dụng Mã Visual Studio trên Hộp cát dành cho nhà phát triển không?

Red Hat Developer Sandbox chưa được cập nhật lên OpenShift Dev Spaces và không thể sử dụng CodeReady Workspaces 2.15 để cung cấp môi trường phát triển dựa trên Visual Studio Code . Nhưng DevWorkspace Operator, công cụ môi trường dành cho nhà phát triển mới được OpenShift Dev Spaces sử dụng, được cài đặt trên Developer Sandbox (vì Web Terminal phụ thuộc vào nó) và nó hỗ trợ chạy môi trường phát triển dựa trên Visual Studio Code.

Dưới đây là một số hướng dẫn dòng lệnh để thực hiện điều đó từ OpenShift Web Terminal. Bạn có thể xem kết quả trong Hình 4.

VSCODE_SAMPLE_DW="https://eclipse-che.github.io/che-devfile-registry/main/devfiles/nodejs/devworkspace-che-code-insiders.yaml"
 
curl  -sSL "${VSCODE_SAMPLE_DW}" | sed 's/^[[:space:]]\{8,\}container:/        container:^          env: [{name: CODE_HOST, value: "0.0.0.0"}]/g' | # <-- CHE IS NOT THERE
sed 's/template:/template:^    attributes:^      controller.devfile.io\/storage-type: ephemeral/g' | # <-- EPHEMERAL IS FASTER
sed 's/volume: {}/volume: {ephemeral: true}/g' |
sed '/tkn=eclipse-che/d' |
tr '^' '\n' | \
oc apply -f -
oc get dw nodejs-web-app --watch

Chạy mã Visual Studio trong Red Hat Developer Sandbox bằng DevWorkspace Operator

Hình 4: Chạy Visual Studio Code trong Red Hat Developer Sandbox bằng DevWorkspace Operator

Chúng tôi vẫn đang nỗ lực mở rộng hỗ trợ trình chỉnh sửa trong OpenShift Dev Spaces. Nhưng bằng cách làm theo các bước được nêu ở đây, người dùng có thể tận dụng sự quen thuộc của họ với Visual Studio Code và hệ sinh thái các tiện ích mở rộng của nó ngay hôm nay.

Đặc biệt cảm ơn Rick Wagner và Florent Benoit đã đánh giá và góp ý cho bài viết này.

Liên kết: https://developers.redhat.com/articles/2022/07/12/how-run-vs-code-openshift-dev-spaces#is_it_possible_to_use_visual_studio_code_on_the_developer_sandbox_

#visualstudiocode #openshift 

Autumn  Blick

Autumn Blick

1598839687

How native is React Native? | React Native vs Native App Development

If you are undertaking a mobile app development for your start-up or enterprise, you are likely wondering whether to use React Native. As a popular development framework, React Native helps you to develop near-native mobile apps. However, you are probably also wondering how close you can get to a native app by using React Native. How native is React Native?

In the article, we discuss the similarities between native mobile development and development using React Native. We also touch upon where they differ and how to bridge the gaps. Read on.

A brief introduction to React Native

Let’s briefly set the context first. We will briefly touch upon what React Native is and how it differs from earlier hybrid frameworks.

React Native is a popular JavaScript framework that Facebook has created. You can use this open-source framework to code natively rendering Android and iOS mobile apps. You can use it to develop web apps too.

Facebook has developed React Native based on React, its JavaScript library. The first release of React Native came in March 2015. At the time of writing this article, the latest stable release of React Native is 0.62.0, and it was released in March 2020.

Although relatively new, React Native has acquired a high degree of popularity. The “Stack Overflow Developer Survey 2019” report identifies it as the 8th most loved framework. Facebook, Walmart, and Bloomberg are some of the top companies that use React Native.

The popularity of React Native comes from its advantages. Some of its advantages are as follows:

  • Performance: It delivers optimal performance.
  • Cross-platform development: You can develop both Android and iOS apps with it. The reuse of code expedites development and reduces costs.
  • UI design: React Native enables you to design simple and responsive UI for your mobile app.
  • 3rd party plugins: This framework supports 3rd party plugins.
  • Developer community: A vibrant community of developers support React Native.

Why React Native is fundamentally different from earlier hybrid frameworks

Are you wondering whether React Native is just another of those hybrid frameworks like Ionic or Cordova? It’s not! React Native is fundamentally different from these earlier hybrid frameworks.

React Native is very close to native. Consider the following aspects as described on the React Native website:

  • Access to many native platforms features: The primitives of React Native render to native platform UI. This means that your React Native app will use many native platform APIs as native apps would do.
  • Near-native user experience: React Native provides several native components, and these are platform agnostic.
  • The ease of accessing native APIs: React Native uses a declarative UI paradigm. This enables React Native to interact easily with native platform APIs since React Native wraps existing native code.

Due to these factors, React Native offers many more advantages compared to those earlier hybrid frameworks. We now review them.

#android app #frontend #ios app #mobile app development #benefits of react native #is react native good for mobile app development #native vs #pros and cons of react native #react mobile development #react native development #react native experience #react native framework #react native ios vs android #react native pros and cons #react native vs android #react native vs native #react native vs native performance #react vs native #why react native #why use react native

Openshift Vs Kubernetes: Difference Between Openshift & Kubernetes

OpenShift and Kubernetes are based on containerization. It can be considered as bundling of different applications for effective development, management, and deployment across different infrastructures. It enables scalability and offers more efficient application development. More than 75% of Businesses are expected to leverage containerization by 2022.

Source

This article is about the two commonly used platforms: OpenShift and Kubernetes. Let’s have a look at their features and differences.

What Is Kubernetes?

Kubernetes is an open-source container orchestration project that helps users manage clustered groups of hosts running Linux containers. It is a portable containerization system, helping developers in service management. Some of the features are automatic application deployment, operations, scaling, container balancing, self-monitoring, etc.

#full stack development #comparison #difference between #kubernetes #kubernetes vs openshift #openshift

Josefa  Corwin

Josefa Corwin

1659852060

A Template Language That Completely Separates Structure and Logic/Ruby

Curly

Curly is a template language that completely separates structure and logic. Instead of interspersing your HTML with snippets of Ruby, all logic is moved to a presenter class.

Installing

Installing Curly is as simple as running gem install curly-templates. If you're using Bundler to manage your dependencies, add this to your Gemfile

gem 'curly-templates'

Curly can also install an application layout file, replacing the .erb file commonly created by Rails. If you wish to use this, run the curly:install generator.

$ rails generate curly:install

How to use Curly

In order to use Curly for a view or partial, use the suffix .curly instead of .erb, e.g. app/views/posts/_comment.html.curly. Curly will look for a corresponding presenter class named Posts::CommentPresenter. By convention, these are placed in app/presenters/, so in this case the presenter would reside in app/presenters/posts/comment_presenter.rb. Note that presenters for partials are not prepended with an underscore.

Add some HTML to the partial template along with some Curly components:

<!-- app/views/posts/_comment.html.curly -->
<div class="comment">
  <p>
    {{author_link}} posted {{time_ago}} ago.
  </p>

  {{body}}

  {{#author?}}
    <p>{{deletion_link}}</p>
  {{/author?}}
</div>

The presenter will be responsible for providing the data for the components. Add the necessary Ruby code to the presenter:

# app/presenters/posts/comment_presenter.rb
class Posts::CommentPresenter < Curly::Presenter
  presents :comment

  def body
    SafeMarkdown.render(@comment.body)
  end

  def author_link
    link_to @comment.author.name, @comment.author, rel: "author"
  end

  def deletion_link
    link_to "Delete", @comment, method: :delete
  end

  def time_ago
    time_ago_in_words(@comment.created_at)
  end

  def author?
    @comment.author == current_user
  end
end

The partial can now be rendered like any other, e.g. by calling

render 'comment', comment: comment
render comment
render collection: post.comments

Curly components are surrounded by curly brackets, e.g. {{hello}}. They always map to a public method on the presenter class, in this case #hello. Methods ending in a question mark can be used for conditional blocks, e.g. {{#admin?}} ... {{/admin?}}.

Identifiers

Curly components can specify an identifier using the so-called dot notation: {{x.y.z}}. This can be very useful if the data you're accessing is hierarchical in nature. One common example is I18n:

<h1>{{i18n.homepage.header}}</h1>
# In the presenter, the identifier is passed as an argument to the method. The
# argument will always be a String.
def i18n(key)
  translate(key)
end

The identifier is separated from the component name with a dot. If the presenter method has a default value for the argument, the identifier is optional – otherwise it's mandatory.

Attributes

In addition to an identifier, Curly components can be annotated with attributes. These are key-value pairs that affect how a component is rendered.

The syntax is reminiscent of HTML:

<div>{{sidebar rows=3 width=200px title="I'm the sidebar!"}}</div>

The presenter method that implements the component must have a matching keyword argument:

def sidebar(rows: "1", width: "100px", title:); end

All argument values will be strings. A compilation error will be raised if

  • an attribute is used in a component without a matching keyword argument being present in the method definition; or
  • a required keyword argument in the method definition is not set as an attribute in the component.

You can define default values using Ruby's own syntax. Additionally, if the presenter method accepts arbitrary keyword arguments using the **doublesplat syntax then all attributes will be valid for the component, e.g.

def greetings(**names)
  names.map {|name, greeting| "#{name}: #{greeting}!" }.join("\n")
end
{{greetings alice=hello bob=hi}}
<!-- The above would be rendered as: -->
alice: hello!
bob: hi!

Note that since keyword arguments in Ruby are represented as Symbol objects, which are not garbage collected in Ruby versions less than 2.2, accepting arbitrary attributes represents a security vulnerability if your application allows untrusted Curly templates to be rendered. Only use this feature with trusted templates if you're not on Ruby 2.2 yet.

Conditional blocks

If there is some content you only want rendered under specific circumstances, you can use conditional blocks. The {{#admin?}}...{{/admin?}} syntax will only render the content of the block if the admin? method on the presenter returns true, while the {{^admin?}}...{{/admin?}} syntax will only render the content if it returns false.

Both forms can have an identifier: {{#locale.en?}}...{{/locale.en?}} will only render the block if the locale? method on the presenter returns true given the argument "en". Here's how to implement that method in the presenter:

class SomePresenter < Curly::Presenter
  # Allows rendering content only if the locale matches a specified identifier.
  def locale?(identifier)
    current_locale == identifier
  end
end

Furthermore, attributes can be set on the block. These only need to be specified when opening the block, not when closing it:

{{#square? width=3 height=3}}
  <p>It's square!</p>
{{/square?}}

Attributes work the same way as they do for normal components.

Collection blocks

Sometimes you want to render one or more items within the current template, and splitting out a separate template and rendering that in the presenter is too much overhead. You can instead define the template that should be used to render the items inline in the current template using the collection block syntax.

Collection blocks are opened using an asterisk:

{{*comments}}
  <li>{{body}} ({{author_name}})</li>
{{/comments}}

The presenter will need to expose the method #comments, which should return a collection of objects:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def comments
    @post.comments
  end
end

The template within the collection block will be used to render each item, and it will be backed by a presenter named after the component – in this case, comments. The name will be singularized and Curly will try to find the presenter class in the following order:

  • Posts::ShowPresenter::CommentPresenter
  • Posts::CommentPresenter
  • CommentPresenter

This allows you some flexibility with regards to how you want to organize these nested templates and presenters.

Note that the nested template will only have access to the methods on the nested presenter, but all variables passed to the "parent" presenter will be forwarded to the nested presenter. In addition, the current item in the collection will be passed, as well as that item's index in the collection:

class Posts::CommentPresenter < Curly::Presenter
  presents :post, :comment, :comment_counter

  def number
    # `comment_counter` is automatically set to the item's index in the collection,
    # starting with 1.
    @comment_counter
  end

  def body
    @comment.body
  end

  def author_name
    @comment.author.name
  end
end

Collection blocks are an alternative to splitting out a separate template and rendering that from the presenter – which solution is best depends on your use case.

Context blocks

While collection blocks allow you to define the template that should be used to render items in a collection right within the parent template, context blocks allow you to define the template for an arbitrary context. This is very powerful, and can be used to define widget-style components and helpers, and provide an easy way to work with structured data. Let's say you have a comment form on your page, and you'd rather keep the template inline. A simple template could look like:

<!-- post.html.curly -->
<h1>{{title}}</h1>
{{body}}

{{@comment_form}}
  <b>Name: </b> {{name_field}}<br>
  <b>E-mail: </b> {{email_field}}<br>
  {{comment_field}}

  {{submit_button}}
{{/comment_form}}

Note that an @ character is used to denote a context block. Like with collection blocks, a separate presenter class is used within the block, and a simple convention is used to find it. The name of the context component (in this case, comment_form) will be camel cased, and the current presenter's namespace will be searched:

class PostPresenter < Curly::Presenter
  presents :post
  def title; @post.title; end
  def body; markdown(@post.body); end

  # A context block method *must* take a block argument. The return value
  # of the method will be used when rendering. Calling the block argument will
  # render the nested template. If you pass a value when calling the block
  # argument it will be passed to the presenter.
  def comment_form(&block)
    form_for(Comment.new, &block)
  end

  # The presenter name is automatically deduced.
  class CommentFormPresenter < Curly::Presenter
    # The value passed to the block argument will be passed in a parameter named
    # after the component.
    presents :comment_form

    # Any parameters passed to the parent presenter will be forwarded to this
    # presenter as well.
    presents :post

    def name_field
      @comment_form.text_field :name
    end

    # ...
  end
end

Context blocks were designed to work well with Rails' helper methods such as form_for and content_tag, but you can also work directly with the block. For instance, if you want to directly control the value that is passed to the nested presenter, you can call the call method on the block yourself:

def author(&block)
  content_tag :div, class: "author" do
    # The return value of `call` will be the result of rendering the nested template
    # with the argument. You can post-process the string if you want.
    block.call(@post.author)
  end
end

Context shorthand syntax

If you find yourself opening a context block just in order to use a single component, e.g. {{@author}}{{name}}{{/author}}, you can use the shorthand syntax instead: {{author:name}}. This works for all component types, e.g.

{{#author:admin?}}
  <p>The author is an admin!</p>
{{/author:admin?}}

The syntax works for nested contexts as well, e.g. {{comment:author:name}}. Any identifier and attributes are passed to the target component, which in this example would be {{name}}.

Setting up state

Although most code in Curly presenters should be free of side effects, sometimes side effects are required. One common example is defining content for a content_for block.

If a Curly presenter class defines a setup! method, it will be called before the view is rendered:

class PostPresenter < Curly::Presenter
  presents :post

  def setup!
    content_for :title, post.title

    content_for :sidebar do
      render 'post_sidebar', post: post
    end
  end
end

Escaping Curly syntax

In order to have {{ appear verbatim in the rendered HTML, use the triple Curly escape syntax:

This is {{{escaped}}.

You don't need to escape the closing }}.

Comments

If you want to add comments to your Curly templates that are not visible in the rendered HTML, use the following syntax:

{{! This is some interesting stuff }}

Presenters

Presenters are classes that inherit from Curly::Presenter – they're usually placed in app/presenters/, but you can put them anywhere you'd like. The name of the presenter classes match the virtual path of the view they're part of, so if your controller is rendering posts/show, the Posts::ShowPresenter class will be used. Note that Curly is only used to render a view if a template can be found – in this case, at app/views/posts/show.html.curly.

Presenters can declare a list of accepted variables using the presents method:

class Posts::ShowPresenter < Curly::Presenter
  presents :post
end

A variable can have a default value:

class Posts::ShowPresenter < Curly::Presenter
  presents :post
  presents :comment, default: nil
end

Any public method defined on the presenter is made available to the template as a component:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def title
    @post.title
  end

  def author_link
    # You can call any Rails helper from within a presenter instance:
    link_to author.name, profile_path(author), rel: "author"
  end

  private

  # Private methods are not available to the template, so they're safe to
  # use.
  def author
    @post.author
  end
end

Presenter methods can even take an argument. Say your Curly template has the content {{t.welcome_message}}, where welcome_message is an I18n key. The following presenter method would make the lookup work:

def t(key)
  translate(key)
end

That way, simple ``functions'' can be added to the Curly language. Make sure these do not have any side effects, though, as an important part of Curly is the idempotence of the templates.

Layouts and content blocks

Both layouts and content blocks (see content_for) use yield to signal that content can be inserted. Curly works just like ERB, so calling yield with no arguments will make the view usable as a layout, while passing a Symbol will make it try to read a content block with the given name:

# Given you have the following Curly template in
# app/views/layouts/application.html.curly
#
#   <html>
#     <head>
#       <title>{{title}}</title>
#     </head>
#     <body>
#       <div id="sidebar">{{sidebar}}</div>
#       {{body}}
#     </body>
#   </html>
#
class ApplicationLayout < Curly::Presenter
  def title
    "You can use methods just like in any other presenter!"
  end

  def sidebar
    # A view can call `content_for(:sidebar) { "some HTML here" }`
    yield :sidebar
  end

  def body
    # The view will be rendered and inserted here:
    yield
  end
end

Rails helper methods

In order to make a Rails helper method available as a component in your template, use the exposes_helper method:

class Layouts::ApplicationPresenter < Curly::Presenter
  # The components {{sign_in_path}} and {{root_path}} are made available.
  exposes_helper :sign_in_path, :root_path
end

Testing

Presenters can be tested directly, but sometimes it makes sense to integrate with Rails on some levels. Currently, only RSpec is directly supported, but you can easily instantiate a presenter:

SomePresenter.new(context, assigns)

context is a view context, i.e. an object that responds to render, has all the helper methods you expect, etc. You can pass in a test double and see what you need to stub out. assigns is the hash containing the controller and local assigns. You need to pass in a key for each argument the presenter expects.

Testing with RSpec

In order to test presenters with RSpec, make sure you have rspec-rails in your Gemfile. Given the following presenter:

# app/presenters/posts/show_presenter.rb
class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def body
    Markdown.render(@post.body)
  end
end

You can test the presenter methods like this:

# You can put this in your `spec_helper.rb`.
require 'curly/rspec'

# spec/presenters/posts/show_presenter_spec.rb
describe Posts::ShowPresenter, type: :presenter do
  describe "#body" do
    it "renders the post's body as Markdown" do
      assign(:post, double(:post, body: "**hello!**"))
      expect(presenter.body).to eq "<strong>hello!</strong>"
    end
  end
end

Note that your spec must be tagged with type: :presenter.

Examples

Here is a simple Curly template – it will be looked up by Rails automatically.

<!-- app/views/posts/show.html.curly -->
<h1>{{title}}<h1>
<p class="author">{{author}}</p>
<p>{{description}}</p>

{{comment_form}}

<div class="comments">
  {{comments}}
</div>

When rendering the template, a presenter is automatically instantiated with the variables assigned in the controller or the render call. The presenter declares the variables it expects with presents, which takes a list of variables names.

# app/presenters/posts/show_presenter.rb
class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def title
    @post.title
  end

  def author
    link_to(@post.author.name, @post.author, rel: "author")
  end

  def description
    Markdown.new(@post.description).to_html.html_safe
  end

  def comments
    render 'comment', collection: @post.comments
  end

  def comment_form
    if @post.comments_allowed?
      render 'comment_form', post: @post
    else
      content_tag(:p, "Comments are disabled for this post")
    end
  end
end

Caching

Caching is handled at two levels in Curly – statically and dynamically. Static caching concerns changes to your code and templates introduced by deploys. If you do not wish to clear your entire cache every time you deploy, you need a way to indicate that some view, helper, or other piece of logic has changed.

Dynamic caching concerns changes that happen on the fly, usually made by your users in the running system. You wish to cache a view or a partial and have it expire whenever some data is updated – usually whenever a specific record is changed.

Dynamic Caching

Because of the way logic is contained in presenters, caching entire views or partials by the data they present becomes exceedingly straightforward. Simply define a #cache_key method that returns a non-nil object, and the return value will be used to cache the template.

Whereas in ERB you would include the cache call in the template itself:

<% cache([@post, signed_in?]) do %>
  ...
<% end %>

In Curly you would instead declare it in the presenter:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def cache_key
    [@post, signed_in?]
  end
end

Likewise, you can add a #cache_duration method if you wish to automatically expire the fragment cache:

class Posts::ShowPresenter < Curly::Presenter
  ...

  def cache_duration
    30.minutes
  end
end

In order to set any cache option, define a #cache_options method that returns a Hash of options:

class Posts::ShowPresenter < Curly::Presenter
  ...

  def cache_options
    { compress: true, namespace: "my-app" }
  end
end

Static Caching

Static caching will only be enabled for presenters that define a non-nil #cache_key method (see Dynamic Caching.)

In order to make a deploy expire the cache for a specific view, set the version of the view to something new, usually by incrementing by one:

class Posts::ShowPresenter < Curly::Presenter
  version 3

  def cache_key
    # Some objects
  end
end

This will change the cache keys for all instances of that view, effectively expiring the old cache entries.

This works well for views, or for partials that are rendered in views that themselves are not cached. If the partial is nested within a view that is cached, however, the outer cache will not be expired. The solution is to register that the inner partial is a dependency of the outer one such that Curly can automatically deduce that the outer partial cache should be expired:

class Posts::ShowPresenter < Curly::Presenter
  version 3
  depends_on 'posts/comment'

  def cache_key
    # Some objects
  end
end

class Posts::CommentPresenter < Curly::Presenter
  version 4

  def cache_key
    # Some objects
  end
end

Now, if the version of Posts::CommentPresenter is bumped, the cache keys for both presenters would change. You can register any number of view paths with depends_on.

Curly integrates well with the caching mechanism in Rails 4 (or Cache Digests in Rails 3), so the dependencies defined with depends_on will be tracked by Rails. This will allow you to deploy changes to your templates and have the relevant caches automatically expire.

Thanks

Thanks to Zendesk for sponsoring the work on Curly.

Contributors

Build Status


Author: zendesk
Source code: https://github.com/zendesk/curly

#ruby   #ruby-on-rails 

PWA vs Native App: Which Is Better Option In 2021?

Every year, the world is expanding with the launch of new smartphones and other gadgets available in the market. According to Statista, more than 50% of the population will be using smartphones by the end of 2021.

Hence, businesses worldwide have understood the importance of smartphones and are joining the mobile industry by launching native apps.

Apart from native apps, progressive web apps is another technology that is gaining a lot of attention among businesses. Moreover, various leading companies worldwide have openly accepted PWA and built progressive web apps.

Now, the question arises, how is PWA different from the native apps? Read More

#pwa vs native #pwa vs native app #progressive web app vs native #progressive web app vs native app #pwa vs native app performance