+ Holy war: XML vs JSON vs HTML + How we use JSON.parse vs XML parsers + We could've made an XML.parse
Если вы когда-нибудь слышали о JSON или JWT, но не использовали JSON - это так красиво просто. Здесь у нас есть объект типа Cake, класс C # на нашем сервере, но отправляемый нам в виде текста, когда мы посещаем мой веб-сайт. Отсюда JavaScript берет этот текст, а затем снова превращает его в объект Cake. Давай посмотрим:
Это функция JavaScript, которая преобразует текст в торты. По крайней мере, попробую.
В обычном JavaScript вы можете взять текст JSON, а затем превратить его в настоящий JS-объект. В VSCode каждый раз, когда вы используете make(), он будет знать, какие свойства будет у объекта return.
Вы можете ввести my_obj., и VSCode сразу же покажет вам список:
Properties of Cake objects flavor: string sweetness: number frosting: boolean
Просто вау. Все это происходит с использованием JavaScript, а не TypeScript или JSDocs.
Чтение JSON вручную, вставка его в блокнот или консоль - не лучший опыт. Преобразование JSON в объекты JavaScript, заставить ваш редактор кода перечислить все свойства вместе с типами - только на JavaScript - невероятно.
+ What did we use before JSON? + What could we have done to get closer to today?
XML, попытка заменить HTML
Заголовок - не шутка.
В свое время HTML был на пути к строгому соответствию стандарту XML. Правила XML не такие добрые, как HTML. Посмотри:
1. You don't need ending </li> tags in HTML 2. HTML knows <br> or <hr> close themselves 3. HTML does not need quotes around element ids (id=applesauce)
По мере того, как продолжались споры о принуждении HTML к согласованию с XML, веб-серверам требовался способ отправки данных веб-клиентам. Возникло то, что под названием AJAX (сегодня мы называем это, используя JavaScript fetch()).
Идея о том, что веб-страницы могут запрашивать дополнительные данные без перехода на новую страницу, казалась более чем привлекательной.
Как серверы выбирают отправку данных в браузеры?
Используя XML! Излишне многословный, пытающийся заменить HTML, не подходящий для медленного интернет-соединения - XML.
Веб-серверы с радостью создали фреймворки для преобразования данных в длинные строки XML. Строки, которые было бы гораздо труднее преобразовать обратно в структурированные данные один раз в JavaScript. Но почему? Почему было труднее deserialize преобразовать XML в объекты, чем серверам serialize преобразовать их в текст?
Почему XML.parse () никогда не существовал
Как выглядит синтаксический анализ в XML?
Вот несколько общих встроенных функций, которые мы используем для синтаксического анализа XML.
Знакомо ли это с тем, как мы взаимодействуем с чем-то еще в JavaScript?
Насколько разумно для нас взаимодействовать с XML, нашим методом передачи объектных данных на сервер или с сервера, точно так же, как мы взаимодействуем с HTML?
Конечно, учитывая контекст того времени, становится понятно, ПОЧЕМУ у обоих был один и тот же API. В то же время бесполезно, чтобы серверы создавали XML автоматически, не используя ни одной строчки пользовательского кода, но не предоставляя возможности сделать то же самое - после того, как данные достигнут места назначения.
In JavaScript, there was no XML.parse; there was never going to be one.
Но мы можем сделать это. Тогда использовали только инструменты.
Для веб-серверов в то время W3C стандартизировал отправку данных внутри чего-то, что называлось SOAP: Envelopes. Казалось бы, способ удвоить размер XML - потому что он и так не был достаточно подробным. Хотя (поддержала Microsoft), это был стандарт; извините, что не добавили .parse(). Что-то вроде SOAP.parse() для сериализации чрезвычайно подробных XML-строк, которые будет отправлять сервер.
No SOAP.parse() ever shipped in a browser version from any vendor.
Как можно упростить XML DomParser API
Чтобы сделать наш API похожим на API JSON, вот как он будет выглядеть при использовании: XML.some_function(xml_var).
Мы можем заставить это работать даже в самых ранних браузерах. Нам нужен один объект с некоторыми именами свойств, которые указывают на функции.
Что делает код?
Эта часть не слишком сложная, наша цель - скрыть огромные имена функций внутри красивых, коротких функций.
Кроме того, было бы неплохо набрать XML., как мы это делаем для JSON., это то, что делает const XML = { … }.
Для справки, не вставляйте это в какой-нибудь браузер IE, который вы забыли, который все еще находится на вашем ноутбуке с Windows. В нашем примере кода используются параметры по умолчанию, параметры функции со знаками равенства, за которыми следует некоторое значение. Здесь мы используем = new Document() вместе с = “”.
Ни одна из версий Internet Explorer не поддерживает это, но позволяет VSCode знать типы каждой переменной. Это помогает нам писать JavaScript, потому что наш редактор кода обычно может сообщать нам возможные функции или свойства внутри любой переменной.
Посмотрим, как это будет работать
На самом деле это не совсем очевидно, даже если знать, что такое xml или tag. Обратите внимание, мы получаем первый элемент, который соответствует приведенному нами описанию. Затем мы return первая имеющаяся точка данных.
Вот пример:
Эта функция может оказаться бесполезной. Обычно нам не нужен только первый элемент, который каждый раз соответствует нашему поисковому запросу, но это только начало.
Остальные наши функции будут построены на этом.
Затем давайте создадим объект JavaScript. Мы почти закончили!
XML.get (), XML.obj ()
Эти две функции работают вместе для deserialize преобразования текста в объекты JavaScript.
Мы используем синтаксический анализатор XML made-for-html для создания объектов JavaScript точно так же, как это делает JSON.parse ().
Функция похожа на XML.get(); это потому, что наши объекты XML названы. Название наших объектов - «Фрукты». Нам нужно получить все элементы с тегом, который соответствует «Fruit». Затем мы будем deserialize каждый объект с XML.obj() - функцией, вызывающей XML.get()!
Попробуем это на массивах.
Это последняя функция, с помощью которой можно начать обрабатывать XML, как веб-серверы в начале 2000-х годов. Представление данных в форме объекта. Точки данных, ключи которых привязаны к значениям. Строка к строке. Строка к числу. Или преобразовать в логическое значение. JSON.parse () намного сложнее. Наш код не понимает, как обрабатывать вложенные объекты.
Still, this 40-or-so line library gets us so much closer to JSON.parse() than the native API did by itself.
Разве тогда это действительно сработало бы?
Удивительно, но совершенно. Посмотрим, что у нас есть:
1. JSON.parse()-like syntax (static class methods) 2. Reading XML tag values 3. Building objects from string keys 4. deserialize arrays of objects
Неплохо! Мы уже подготовили большинство из этих IE 6
Мы уже рассмотрели, как выполнить пункт 1. До того, как JSON был кодифицирован, в JS не было ключевых слов class или static. Тем не менее, JavaScript был разработан, чтобы позволить использовать функции как свойства объекта. Выглядит это так:
А как насчет пункта 2?
Как ни странно, независимо от того, насколько сильно изменится Интернет, приведенный выше код получит внутренние данные тега XML так же хорошо, как в IE 6, как и прямо сейчас, если вы попытаетесь запустить наш пример.
Структура свойств JavaScript Document пережила популярность стандарта (XML), для которого она была создана.
Номер 3.
В этом вся прелесть (или ужас) JS. Объекты - это просто списки ключевых значений. Если вы хотите добавить свойства к объекту во время выполнения, поместите после него [ ] с переменной, которую вы хотите использовать внутри них.
Да, в JavaScript все объекты работают как словари на других языках.
Объединение всех этих функций подводит нас к четвертому.
Вот и все.
Однако настоящий XML.parse() сможет создать объект, обнаруживая свойства случайного XML, а также извлекая сложные значения свойств.
Возможно ли создать настоящий XML.parse (), который соответствует настоящей повторной сериализации данных?
Подведем итог двум пунктам:
1. Loop over random object properties via for has always been in JS. 2. .hasOwnProperty() has existed in Internet Explorer - since the year 2000.
В настоящее время не кажется большой необходимости в синтаксическом анализаторе XML такого калибра, но если вы хотите продолжить в нашем путешествии по переносу настоящего в прошлое, из прошлого в настоящее, делая случайные снимки в будущее - у нас в запасе гораздо больше.
