2015-11-24 3 views
3

Я работаю над проектом Ruby/React. Мы используем Реагировать компоненты и CoffeeScript и окончательный JS собран Звездочкой:Рекомендации по импорту глубоко вложенных компонентов Javascript

#= require org/components/whatever 

{ Whatever } = Org.Components 

Это хорошо, когда есть не слишком много вложенности, а затем вы wrtiting что-то вроде этого:

#= require org/components/whatever 
#= require org/components/something/else/whatever 

{ Whatever1 } = Org.Components 
{ Whatever2 } = Org.Components.Something.Else 

Сегодня я пытался найти, где используется Org.Components.Image.Upload. Но иногда он импортируется как { Upload } или используется как Image.Upload, и это не облегчает задачу.

Теперь я думаю, возможно, не идти дальше, чем Org.Components для импорта. Поэтому, если вам нужно Image.Upload - получите { Image } = Org.Components и используйте Image.Upload. Если он слишком длинный - назначьте переменную.

#= require org/components/image 

{Image} = Org.Components 
Upload = Image.Super.Complex.Upload 

# Or use it like this for explicitness 
render: -> 
    Image.Super.Complex.Upload 

Какова наилучшая практика здесь? Я хочу, чтобы код был доступен для поиска.

+0

Локальных ссылки на объекты могут помочь уменьшить время поиска, что то, что кажется, что вы делаете, но если он организован, то _Dependency Декларация Pattern_ может быть очень полезным и удобно. – ZachPerkitny

+0

Обычно я использую этот метод при работе с глубоко вложенными объектами. – ZachPerkitny

+0

Я не думаю, что есть лучшая практика. Но вы, конечно же, не должны смешивать их, используйте * либо * destructuring *, либо * назначение переменной. – Bergi

ответ

0

Если вы находитесь в среде CommonJS (Node) и, возможно, используете модуль, например Webpack или Browserify, вы можете воспользоваться прямым импортом модулей. Например:

Вместо того чтобы делать это Org.Components.Image, вы можете сделать это:

import Upload from 'org/components/Image/Super/Complex/Upload' 
// or var Image = require('org/components/Image/Super/Complex/Upload'); 

В вашей первоначальной стратегии, вы загружаете всю библиотеку (орг) для дальнейшей фильтрации его до Upload.

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

+0

Вопрос в том, что если я повторно использую Image.Upload отдельно – firedev

+0

Извините, если у меня возникли неправильные вопросы. Но точка, которую я пытаюсь сделать, - всегда ссылаться только на модуль, который вы ищете в данной зависимости. В вашем сценарии я бы сказал, что наилучшей практикой является всегда устанавливать весь путь для компонента Upload. Надеюсь, у меня есть смысл здесь. –

0

Чтобы прекратить боевые действия против звездочек я определил компонент Root, который говорит Звездочки, где искать подкомпонент:

# components/branding.coffee 

#= require_tree ./branding 

Org.Components.Branding = {} 

Так что теперь, если мне нужно что-нибудь от брендинга поддерева я просто сделать следующее:

#= require org/components/branding 

{div} = React.DOM 

{Branding} = Org.Components 

Org.defineComponent "Settings.Branding", 
    render: -> 
    div {}, 
     Branding.Edit.ContactUs {} 
     Branding.Config {}, 
     Branding.Edit 

Таким образом, мне не нужно беспокоиться о зависимостях и находить его приятнее работать.

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

Branding.Config - это обернутая информация, которая загружает и синхронизирует настройки. В приведенном выше примере он используется для загрузки настроек для страницы Brading.Edit. И здесь он загружает брендинг в «Layouts.Default».

И снова я только требую branding

# apps/src/org/components/layouts/default.coffee 

#= require org/components/branding 

{Branding, TenantStateBar, UnsupportedBrowserBar} = Org.Components 

Org.defineComponent 'Layouts.Default', 
    render: -> 
    div {}, 
     Branding.Config {}, 
     Branding.Style 
Смежные вопросы