За последние 2 дня в D3 Slack шла эпическая дискуссия. Далее следует мой взгляд на некоторые из поднятых вопросов, некоторые мои собственные животрепещущие вопросы и некоторые идеи решений.
По теме написано: D3 - это не библиотека визуализации данных, Проблема с D3.
Меня особенно заинтриговал вопрос о монолите `‹ script src = ”d3.js” ›` против инструментов сборки + микромодулей D3 + других библиотек. Я действительно не уверен, что является «лучшим» для преподавания / обучения, а также для отработки датавиза и публикации работ для встраивания, но я бы действительно хотел бы в этом разобраться.
Подход D3 Monolith
Я обнаружил, что монолит намного лучше (чем использование NPM и инструментов сборки локально) для обучения D3 новичков веб-разработке, потому что мы можем использовать редактор в браузере, такой как JSBin, Blockbuilder, Observable, или Datavis.tech. Однако (наиболее разумное) высказывание Кристин Генри Зачем кому-то пытаться изучить всю библиотеку? можно перевернуть с ног на голову: Зачем кому-то нужно включать всю библиотеку (236 КБ) на свою страницу?.
Ответы имеют смысл для изучения контекстов, например: «Легче использовать новую функцию API, потому что все функции доступны постоянно» или «Время загрузки страницы не имеет значения, потому что это игрушечный пример». Но как насчет перехода от обучения к созданию и публикации реальных визуализаций?
На этом этапе студенты должны изучить множество новых концепций, касающихся Git, хостинга, NPM, инструментов сборки и импорта ES6, которые, как я обнаружил, ломают их после того, как они освоились с D3 monilith (если они раньше не делали Web Dev). Было много отчаяния и сопротивления, и, в конце концов, около 2% студентов смогли вообще что-то работать без монолита. По крайней мере, это был мой опыт преподавания 10 недель университетской визуализации данных в Вустерском политехническом институте прошлой осенью.
Подход к микромодулям D3
Мне нравится концептуальный прорыв и простота простых функций API D3 (например, `select` вместо` d3.select`), которые появляются, когда вы используете подход микромодулей D3. . Это означает, что вы разрабатываете локально в контексте NPM, устанавливаете и объединяете только отдельные пакеты D3, которые вам требуются, и используете импорт ES6, например import {select} from ‘d3-selection'.
Этот подход имеет ряд преимуществ перед «подходом монолита D3». Во-первых, вы получаете готовую сборку «из коробки», которая загружает на страницу один пакет JS. Это подходит для развертывания «настоящих» визуализаций, которые, как ожидается, будут широко просматриваться или встраиваться в статьи. Кроме того, свобода добавления дополнительных модулей NPM волей-неволей является сцеплением. Но для этого вам нужно заняться инструментами сборки, разрабатывать локально, изучить Git и иметь какое-то решение для хостинга.
Изучение всех этих понятий заранее, до того, как вообще коснуться D3, может занять недели и потерять половину студентов.
Что делать?
Я обсуждаю, что делать с предстоящим онлайн-курсом по визуализации данных, который я преподаю осенью. Кстати, этот курс открыт для всех аспирантов университета; если вам интересно, вы можете предварительно зарегистрироваться здесь.
Мне любопытно, знает ли кто-нибудь об удобной среде редактирования кода на основе браузера, которая позволяет:
- Код только в браузере (никаких локальных инструментов)
- Написать стандартный JS-код (без каких-либо редакторов / специфичных для платформы вещей)
- Используйте импорт ES6 из модулей NPM (например, микромодулей D3)
- Публикация работ в Интернете (аналогично bl.ocks.org)
- Экспорт работает как стандартные проекты на основе NPM
- Встраивание работает на других сайтах (например, Medium или WikiTribune)
?
Я считаю, что это было бы оптимальным решением для обучения D3, потому что студенты будут использовать самые современные и масштабируемые методы кодирования, но смогут создавать визуализации данных, не совершая «большого скачка» по настройке инструментов разработки на местном уровне и изучению внутренней работы конфигураций Webpack Babel и тому подобного.
