PHPStorm: How to debug TypeScript

Some time ago, I’ve started to work with Node.JS and its TypeScript. No one serious project get around without debugging. I work with PHPStorm many years, so there were no needs to search another IDE for Node.js, such as PHPStorm has natively support for Node.JS. That sounds great but a debugging approach is slightly different from PHP debugging with xDebug. There are no needs to add special options in .tsconfig.json for compilation process from TypeScript in native JavaScript, PHPStorm will compile code on the fly.

Code preparation

Create main.ts file and add next code for debug: // src/main.ts
let a = 5;
setInterval(() => {
a++;
console.log(a++);
}, 2000);
Set break point on third line and go to next step.

PHPStorm configuration

Click on Edit Configuration... on the right top
In the opened window click the green "+" button (Add New Configuration) and select Node.js
It creates new debug configuration for your script, some options can be applied automatically such as an option Node interpreter.

Fill in:
Node interpreter: the path to your node.exe file
Node parameters: --inspect --require ts-node/register
Working directory: the path to the root of your project
JavaScript file: TypeScript file which you want to debug
Environment variables: NODE_ENV=development

Click ApplyOK
Node parameters options are really important do not forget about them.

Run/Debug Configuration for TypeScript file
Go to filemain.ts, set a breakpoint on line five, click the Debugbutton on the right top, wait for some time while the automatic compilation executing and enjoy debugging process.
It may not be obvious but the debugging process is slightly different from PHP and you should take attention onawait/async constructions which are run asynchronously and they can run not in a normal way. Click buttonStep over several times and magic happens =).

Related links

React: Local state management with Apollo

Базовими речами в React є props та state, це ключові моменти, які потрібно зрозуміти і розібрати.

З props все абсолютно просто – в них передаємо дані на основі яких компоненти промальовуються. Props – це просто контейнер для зберігання даних на рівні компоненту, якщо змінити дані в props, то з компонентом нічого не відбудеться. Геть інша роль відведена для state, якщо змінити state, зараз же запускається перемальовування компоненту. Але потрібно чітко усвідомити, що state можна змінювати тільки через this.setState(), інакше компонент не перемалюється і можливі помилки.

State здебільшого використовується при виникнені події, як то onClick, onSelect, onChange, onSelectRow і т.д. Коли якась подія викликається, в ній можна змінити state компоненту через this.setState(), що в свою черегу запускає перемальовування компоненту.

Є гарна стаття “8 things to learn in React before using Redux“. Спокійно замініть Redux на будь який інший менеджер керування станом (Apollo, MobX), суть статті від того не зміниться, там лише теорія з мінімальними прикладами на React.

State який пропонує React з коробки, досить гарно працює на малих компонентах, зміна стану який впливає лише на них або на найближчих сусідніх компонетів. Але коли зміна стану одного компонету впливає на десяток інших, і потрібно передавати state callback від спільного батька для всіх компонетів в низ по дочірніх компонентах, тоді це стає головним болем розробника з яким складно боротись. Кажучи правду, таке трапляться на середніх і великих проектах, тому відмовлятись від стандартного this.setState() в жодному разі не можна, потрібно лише навчитись це правильно готувати.
Continue reading

Часткове промальовування компонентів React на сервері. Частина 2

Це друга стаття із серії Не стандартна робота з React
Частина 1

В попередній частині) ми поговорили про базову версію реалізації часткового промальовування React компонетів на сервері.

Ми маємо значні напрацювання у відображені табличних даних (ZfcDataGrid) на PHP, було б не зовсім справедливо викинути роки роботи, тільки через те, що почали використовувати React. В данній спробуємо реалізувати новий jqGrid React компонет, який працює на базі jQuery і буде повністю взаємодіяти з сервером.

Не має значення яка бібліотека векористовується на сервері, ми будемо лише отримувати HTML і намагатимемось подружити його з React, тому кроки для інших бібліотек будуть схожі.
Continue reading

Часткове промальовування компонентів React на сервері. Частина 1

Практика описана в даній статті відноситься до Bad Practice, вона надається як зразок для менш болісного перехідного періоду і в майбутньому обов’язково має бути оптимізована під вимоги React.

На початку впровадження нових технологій на проект, не можна все старе викинути і написати код заново, точніше можна, але бізнес це не оцінить.

Припустимо компанія довгий час проводила розробку на PHP, має багато наробіток на GitHub, має сильні знання в стеку технологій які працюють з PHP, але приходить час коли того всього стає мало і потрібно підвищувати рівень. Поява React стала для нас тим каталізатором, коли ми зрозуміли, що чекати немає чого, потрібно діяти.

Саме перше питання, яке виникає при впровадженні React в існуючий проект, як зробити так, щоб і вівці цілі, і вовки ситі?
Перше, що приходить в голову, це отримувати готовий HTML з сервера і запихати його в React, при цьому забороняти компоненту перемальовуватись.
Коли запитуєш в google “react partial server side rendering“, все що він повертає не відповідає бажаному. Всі статті кажуть як нам отримати повну HTML сторінку для конктернього URL, так це теж можна віднести до partial, але нас цікавить промальовування окремих компонентів на сторінці, а не всієї сторінки.
Continue reading

Налаштування зв’язки ZF3+Doctrine2+GraphQL

WEB змінюється дуже швидко. Ще декілька років тому головним mainstream & best practise для реалізації API вважався REST, то сьогодні він вже має багато недоліків і всі використовують GraphQL, як єдино правильний варіант для роботи через API.

Якщо серйозно, то в цих словах багато сарказму, кожен вирішує сам, що є кращим для нього. Свого часу з появою NoSQL баз даних (Mongo) весь Інтернет гудів, що от ми знайшли срібну кулю від усіх бід і тепер заживемо щасливо. Мало того, багато хто ще тоді похоронив SQL бази даних і очікував швидкої їх смерті. Пройшло порядку 10 років, MySQL, MSSQL, PostgreSQL та інші SQL бази даних не вмерли, вони випускають нові релізи і додають в них нові плюшки.

Єдине що дійсно, не потрібно відставати від тенденцій і при нагоді пробувати нові технології, хто зна можливо вони вам сподобаються.
Continue reading

Doctrine 2 SQL Filter and annotation in ZF3

In a certain period of time, a user should see information about one marketplace. It can be tedious to add small WHERE condition each time when you want to work with the marketplace.

Doctrine provides an elegant solution to never forget this condition in your queries.

This approach can be used with Doctrine SQL Filter and Annotation.

This way make your code more simple and readable and increase development speed.
Continue reading

MySQL. Корисні запити

Замінити значення у всіх таблицях одним запитом

SELECT
    CONCAT('UPDATE ', table_schema, '.', table_name, ' SET ', column_name, '=REPLACE(', column_name, ',''glutamine.'',''l-glutamine.'');')
FROM
    information_schema. COLUMNS
WHERE
    table_schema IN ('your_database_name')
    -- AND table_name NOT IN ('table_name') -- exclude table names
AND (
    column_type LIKE 'char(%'
    OR column_type LIKE 'varchar(%'
    OR column_type LIKE '%text'
);

PHP array_udiff: особливості роботи

Документація каже “Вираховує відмінність масивів використовуючи compare_function (callback) для порівняння”. Здається просто, але не зовсім.

Функція використовує принцип сортування, і очікує, що одне з наступних значень -1, 0, 1, буде повернуто з compare_function. На stackoverflow знайшов пояснення як це працює. Продублюю тут: “В compare_function ви можете повернути 0, сказавши, що об’єкти однакові, та -1, сказавши, що вони різні”.

Примітка: Зайнявшись відладкою даної функції, дізнався, що замість -1 можна повертати 1.
Continue reading

Zend Framework Factory performance: ReflectionBasedAbstractFactory vs ConfigAbstractFactory vs Native Factory

Here is comment of @weierophinney about Factory performance in Zend Framework.

Summary of the benchmarks:

The ConfigAbstractFactory runs at around the same speed as any other factory that pulls at least one dependency from the container.
The ReflectionBasedAbstractFactory adds 2-3μs to service creation for a service that pulls at least one dependency from the container; this is essentially the cost of using reflection on the constructor.
The ConfigAbstractFactory runs essentially the same speed whether used as an abstract factory or mapped as a factory; these speeds will, of course, change based on how many abstract factories are in use.
The ReflectionBasedAbstractFactory consistently runs 0.5μs faster when mapped as a factory, regardless of number of dependencies.
Continue reading

Navigation