Подскажите, как в новой версии API передать return_url для ситуации, когда платеж отменили? Сейчас только 1 url можно передать и он будет на ссылке "в магазин" и до оплаты, и после.
Вот как раз это помнить не стоит сразу. Об этом нужно вспомнить, когда это станет проблемой. Оптимизацией нужно заниматься тогда, когда это нужно, как бы это не звучало)
Под рантаймом я как раз и подразумеваю неявные штуки, которые фреймворк/либа делает за меня. Вам про числа уже много написали, что ожидается порой совсем другое. А если вы все же настаиваете на своем, то почему у инпута типа date нет приведения к дате? Или есть?)
Более того, синтаксис — учи еще один язык. Чего стоят только вот такие штуки:
{#await promise then value}
<p>The value is {value}</p>
{/await}
В общем, без полбутылки не разберешься. Писать вот так сразу на нем куда сложнее, чем на vue или react. Там реально есть интуитивные штуки.
Немного про expected result: каков будет expected result для инуптов с type'ом tel или datetime. Для tel еще ладно, string даже норм. А вот для datetime можно и Date сделать, как expected result, дату же выбираем.
И немного про сам Svelte, но это уже ответ не вам, а скорее к автору статьи
Кстати, про input type=«number». Если запустить пример из статьи и стереть значение из input'а, мы получим замечательный результат: undefined + 2 = NaN.
Сразу скажу, я не против Svelte. Но в статье я прям нашел несколько странных для меня моментов.
Кроме этого, мы должны помнить, что необходимо принудительно привести строковое значение в числовое с помощью оператора +, иначе 2 + 2 будет равно 22 вместо 4.
Кажется, явное всегда лучше. Тот факт, что в Svelte есть неявное приведение string к number в случае input type number нужно держать в голове. То есть, разбирая код на Svelte нужно потратить гораздо больше усилий мозга, нежели чем в явных решениях других ребят, что вы привели в статье. Это я про фразу
Поэтому, когда вы читаете такой код, вам придётся приложить гораздо больше усилий, чтобы понять замысел автора.
И в целом, читая доку по Svelte, лично у меня часто возникала мысль, блин, еще и это придется помнить. То есть кода пишем мало, да. Зато в голове теперь весь «рантайм» Svelte загрузить придется. Не спорю, с тем же React придется сделать тоже самое, но там этого «рантайма» куда меньше.
А давайте ты у себя в компании будете решать, кого и когда звать на собеседования и с какими мотивами. Ну и свои сомнения тоже куда подальше засунь. Что-то по рейтингу и карме не скажешь, что у тебя вообще может быть какая-то адекватная точка зрения, Хабр свое дело знает.
Во-первых, есть несколько изданий этой книги разных лет. Я привел 2011, кажется. Во-вторых, иметь знания о том, как можно сделать и принимать решение уже исходя из задачи — вот что должен уметь хороший инженер. Статье, возможно, не хватает информации о том, какие надстройки появились в языке, чтобы не писать столько кода самому, но говорить, что значит этого не надо — это точно неправильно. Да и какая разница, 2016 или 2116 год, если в основе языка это лежит, то знать это надо. А еще надо знать какие возможности есть и как ими пользоваться.
Если новичкам не рассказывать про прототипы, то они даже знать этого не будут. И будут говорить, что в JS есть классы. А что это на самом деле, как работает — это уже не важно. В итоге имеем ребят, которые не знают инструмента, которым пользуются.
А по поводу статьи, я бы просто порекомендовал Шаблоны проектирования Больше и подробнее.
TARS по умолчанию создает 1 хеш на все. С новым релизом хеш поменяется, это да. Никто не мешает этот механизм настроить так, как вам будет удобно.
Скажите, часто ли такое бывает, что вы правите только стили и релизите это? Скорее всего правится еще и JS, и шаблоны. Хотя вот щаблоны могут и не меняться. Часто ли вы меняете только шрифт и релизите?
Согласен. Кажется я знаю, как это можно решить, добавлять хеш в имя папки со статикой, тогда не придется врсионировать каждый файл отдельно. Как вам идея?
1) webpack уже почти в тестировании. 1.7.0 будет максимуму в начале той недельки;
2) если речь идет о тестировании самого TARS, то это не так, сам TARS тестируется. Если речь о том, что workflow нет для тестирования проекта — это да. Задача есть, было бы неплохо, если бы кто-то помог с этим;
3) Объясните, что это значит, пожалуйста.
Про webpack я уже ответил. И тут вопрос не про качество, а про скорость сборки скорее.
По поводу кеширования шрифтов: а зачем хеш для них нужен? Есть вероятность, что вы сделаете другой шрифт под тем же именем? У них внутри в любом случае свое имя зашито и ОС понимает, с каким шрифтом имеет дело исходя не только из названия шрифта. В общем про этот момент не понятно.
Подскажите, как в новой версии API передать return_url для ситуации, когда платеж отменили? Сейчас только 1 url можно передать и он будет на ссылке "в магазин" и до оплаты, и после.
Под рантаймом я как раз и подразумеваю неявные штуки, которые фреймворк/либа делает за меня. Вам про числа уже много написали, что ожидается порой совсем другое. А если вы все же настаиваете на своем, то почему у инпута типа date нет приведения к дате? Или есть?)
Более того, синтаксис — учи еще один язык. Чего стоят только вот такие штуки:
В общем, без полбутылки не разберешься. Писать вот так сразу на нем куда сложнее, чем на vue или react. Там реально есть интуитивные штуки.
И немного про сам Svelte, но это уже ответ не вам, а скорее к автору статьи
Кстати, про input type=«number». Если запустить пример из статьи и стереть значение из input'а, мы получим замечательный результат: undefined + 2 = NaN.
Кажется, явное всегда лучше. Тот факт, что в Svelte есть неявное приведение string к number в случае input type number нужно держать в голове. То есть, разбирая код на Svelte нужно потратить гораздо больше усилий мозга, нежели чем в явных решениях других ребят, что вы привели в статье. Это я про фразу
И в целом, читая доку по Svelte, лично у меня часто возникала мысль, блин, еще и это придется помнить. То есть кода пишем мало, да. Зато в голове теперь весь «рантайм» Svelte загрузить придется. Не спорю, с тем же React придется сделать тоже самое, но там этого «рантайма» куда меньше.
А по поводу статьи, я бы просто порекомендовал Шаблоны проектирования Больше и подробнее.
Скажите, часто ли такое бывает, что вы правите только стили и релизите это? Скорее всего правится еще и JS, и шаблоны. Хотя вот щаблоны могут и не меняться. Часто ли вы меняете только шрифт и релизите?
2) если речь идет о тестировании самого TARS, то это не так, сам TARS тестируется. Если речь о том, что workflow нет для тестирования проекта — это да. Задача есть, было бы неплохо, если бы кто-то помог с этим;
3) Объясните, что это значит, пожалуйста.
Про webpack я уже ответил. И тут вопрос не про качество, а про скорость сборки скорее.
По поводу кеширования шрифтов: а зачем хеш для них нужен? Есть вероятность, что вы сделаете другой шрифт под тем же именем? У них внутри в любом случае свое имя зашито и ОС понимает, с каким шрифтом имеет дело исходя не только из названия шрифта. В общем про этот момент не понятно.