javascript object vs array

Я работаю над плагином JavaScript на работе, который будет принимать массив элементов и отображать его по-своему (сортировка, порядок столбцов, критерий) в таблице. Параметры настройки будут создаваться динамически (свойство date создаст критерии «до» и т. Д.).

Плагин будет использоваться во многих разных проектах, поэтому элементы могут сильно различаться, и по мере настройки дисплея свойства, необходимые для каждого создания таблицы, также различаются.

Должен ли я запрашивать элементы как объекты или массивы?

В принципе (не настоящий код - я не буду использовать foreach;), что сделано:

foreach element in allelements
row=new tablerow
foreach columnid in chosencolumns
    row.add(element[columnid])
table.add(row)

Если каждый элемент является массивом, columnid является индексом, но если каждый элемент будет именем свойства.

Является ли элемент [3] быстрее, чем элемент ['prop3']?

Я создал бета-версию здесь , в которой есть элементы, хранящиеся в виде массивов, но я не уверен, что это лучший/быстрый способ

EDIT: Due to the nature of the project ordering of the properties of an element is not important. ALSO: which way will consume more memory? Some systems will consist of many elements with many properties so memory might be an issue :-/

ВТОРОЙ РЕДАКТИРОВАНИЕ: Если я использую объекты, мне также нужно будет создать массив имен свойств для объекта. Поэтому, если пользователь решил, что представление состоит из 13-го, 2-го и 4-го свойств в качестве столбцов 1, 2 и 3, мне нужно будет сделать следующее для каждого элемента

row.add(element[propertynames[13]])
row.add(element[propertynames[2]])
row.add(element[propertynames[4]])

Если бы я выбрал решение массива, я бы «сохранил» поиск свойств:

row.add(element[13])
row.add(element[2])
row.add(element[4])
2
nl ja de
«Элемент [3] быстрее элемента ['prop3']?" --- Это не имеет значения. Не тратьте впустую свое время, исправляйте ошибки и не выполняйте некоторые действительно полезные вещи.
добавлено автор zerkms, источник
@Rune Jeppesen: реальные задачи. У каждого проекта есть ошибки, задачи и очереди улучшений.
добавлено автор zerkms, источник
@Rune Jeppesen: реальные задачи. У каждого проекта есть ошибки, задачи и очереди улучшений.
добавлено автор zerkms, источник
Просто имейте в виду, что объектные ключи упорядочены not .
добавлено автор Álvaro González, источник
Кроме того, всякий раз, когда вы используете для ... в , обязательно проверяйте hasOwnProperty .
добавлено автор Amadan, источник
@ zerkms Это очень важно. Представьте себе систему среднего размера с 5000 элементами, каждая из которых содержит 20 свойств/полей, а пользователь запрашивает отсортированное представление с 2 критериями. Это потребует много усилий!
добавлено автор Rune Jeppesen, источник
@zerkms кстати: какие ошибки? и какие действительно полезные вещи? :)
добавлено автор Rune Jeppesen, источник

2 ответы

Есть несколько критериев, которые могут быть Аргумент , чтобы предпочесть одну структуру данных над другой, но это привело бы к субъективному обсуждению.

However, the most significant question you should ask yourself is,
do you need/want the data to appear in order and/or sorted?

Если ответ «да», вы должны пойти с Array . Клавиши по спецификации не заданы. Вы можете, конечно, зацикливать и отсортировать ключи, но опять же, это зависит от типа данных и того, как вы хотите его прочитать.


Если вы перейдете с Javascript Array (который все еще является объектом), вам определенно не нужно перебирать содержимое через for..in . Это самый медленный метод для нефункциональных циклов. Перейдите с в то время как , для или do-while .

Похоже, вы говорите о большом большом количестве данных. В общем, вы хотите избежать этого, если это возможно. Попытайтесь прочитать и перенести данные в более мелкие куски, или, может быть, потоковая передача данных может быть лучшим вариантом. Кроме того, если есть много возможностей для передачи, структура данных станет фактором. Как нотация объектов имеет в общем больше информации о структуре , чем простые массивы .

3
добавлено
@RuneJeppesen: Это зависит от того, что вы подразумеваете под «клиентской стороной». Если это означает загрузить все эти данные в DOM браузеров, это в конечном итоге станет ужасным. Если вы просто хотите загружать и кэшировать данные в памяти, это может сработать. Во всяком случае, вы можете не захотеть отходов пользователей с данными, к которым он даже не может получить доступ.
добавлено автор jAndy, источник
Почему следует избегать сохранения клиентской стороны данных? Если данные передаются в более мелкие куски (начиная с самого нового), и у нас нет пользователей телефона/планшетов. Я думаю, что это будет намного быстрее, чем «говорить» с сервером каждый раз, когда пользователи запрашивают новый отчет/представление.
добавлено автор Rune Jeppesen, источник
Я не уверен, загружаю ли данные в браузер DOM - я храню данные в объекте javascript? Также к вашему оригинальному сообщению, касающемуся информации о структуре: Означает ли это, что [['James Bond', 8,40], ['Superman', 9999,36]] использует меньше памяти, чем [{Name, 'James Bond', strength: 8, прохлады: 40}, {{Имя, 'Супермен', сила: 999 & ZWNJ; 9, прохлады: 36}?
добавлено автор Rune Jeppesen, источник

Есть несколько критериев, которые могут быть Аргумент , чтобы предпочесть одну структуру данных над другой, но это привело бы к субъективному обсуждению.

However, the most significant question you should ask yourself is,
do you need/want the data to appear in order and/or sorted?

Если ответ «да», вы должны пойти с Array . Клавиши по спецификации не заданы. Вы можете, конечно, зацикливать и отсортировать ключи, но опять же, это зависит от типа данных и того, как вы хотите его прочитать.


Если вы перейдете с Javascript Array (который все еще является объектом), вам определенно не нужно перебирать содержимое через for..in . Это самый медленный метод для нефункциональных циклов. Перейдите с в то время как , для или do-while .

Похоже, вы говорите о большом большом количестве данных. В общем, вы хотите избежать этого, если это возможно. Попытайтесь прочитать и перенести данные в более мелкие куски, или, может быть, потоковая передача данных может быть лучшим вариантом. Кроме того, если есть много возможностей для передачи, структура данных станет фактором. Как нотация объектов имеет в общем больше информации о структуре , чем простые массивы .

3
добавлено
@RuneJeppesen: Это зависит от того, что вы подразумеваете под «клиентской стороной». Если это означает загрузить все эти данные в DOM браузеров, это в конечном итоге станет ужасным. Если вы просто хотите загружать и кэшировать данные в памяти, это может сработать. Во всяком случае, вы можете не захотеть отходов пользователей с данными, к которым он даже не может получить доступ.
добавлено автор jAndy, источник
Почему следует избегать сохранения клиентской стороны данных? Если данные передаются в более мелкие куски (начиная с самого нового), и у нас нет пользователей телефона/планшетов. Я думаю, что это будет намного быстрее, чем «говорить» с сервером каждый раз, когда пользователи запрашивают новый отчет/представление.
добавлено автор Rune Jeppesen, источник
Я не уверен, загружаю ли данные в браузер DOM - я храню данные в объекте javascript? Также к вашему оригинальному сообщению, касающемуся информации о структуре: Означает ли это, что [['James Bond', 8,40], ['Superman', 9999,36]] использует меньше памяти, чем [{Name, 'James Bond', strength: 8, прохлады: 40}, {{Имя, 'Супермен', сила: 999 & ZWNJ; 9, прохлады: 36}?
добавлено автор Rune Jeppesen, источник
JavaScript Jobs — чат
JavaScript Jobs — чат
8 336 участник(ов)

JavaScript Jobs — чат для поиска работы и людей Правила оформления: https://teletype.in/@telegram-ru/r1WQe5F1m См. также: @mobile_jobs, @devops_jobs, @nodejs_jobs, @react_js, @angular_ru, @js_ru

JavaScript.ru
JavaScript.ru
7 932 участник(ов)

Сообщество сайта JavaScript.ru в Slack.

pro.js
pro.js
4 675 участник(ов)

Про JavaScript и NodeJS Invite: https://t.me/joinchat/Be4rsT5Rsgq30DHutjxXgA Правила: http://telegra.ph/ru-chat-rules-06-19 Вакансии только с ЗП, не чаще раза в неделю.

JavaScript — русскоговорящее сообщество
JavaScript — русскоговорящее сообщество
3 269 участник(ов)

Рекомендуем сразу отключить уведомления Правила: https://rudevs.network/ByaMH6un7 См. также: @js_noobs_ru, @nodejs_ru, @typescript_ru, @react_js, @electron_ru Вакансии и поиск работы: @javascript_jobs

JavaScript Noobs — сообщество новичков
JavaScript Noobs — сообщество новичков
2 484 участник(ов)

Чат для новичков

javascript_ru
javascript_ru
915 участник(ов)

Сообщество любителей самого популярного языка программирования в мире. Чат основан в 2009 году. Логи: https://goo.gl/9EOeM7 Поддержка бота: @chat_linker (ссылка на репу внутри) Вам будут интересны @frontend_ru и @css_ru

jsChat
jsChat
603 участник(ов)

Чат посвященный программированию на языке javaScript Перед отправкой ссылки на Ваш контент посоветуйтесь с админом Все ссылки удаляются ботом автоматически

JavaScript for Zombies Chat
JavaScript for Zombies Chat
492 участник(ов)

Чат про JavaScript для настоящих zombie! Вход строго по приглашениям! Ссылка для строгих приглашений: https://t.me/joinchat/AAMBHz3Uyr0tuZ7VaB029g

All That JS
All That JS
417 участник(ов)

JS на русском