2015-06-21 2 views
0

Предположим, вместо того, чтобы упаковывать разделы onInit и onRender вашей Ractive-декларации в ваш index.html с множеством функций, которым нужен доступ к активному объекту, вы хотите, чтобы index.html был более чистым и более простым и опорным. библиотеки в других файлах.передается в качестве аргумента хорошей практики?

Есть ли какой-либо вред в прохождении Ractive в качестве аргумента, поэтому эти «внешние» функции могут получить к нему доступ?

Например, вместо:

oninit: function() { 
    // tons of code here 
} 

это делает?

oninit: function() {  
    doThisThing(ractive) 
} 

Затем в отдельном файле:

function doThisThing(ractive) { 
    pingAnAPI(function(response) { 
     ractive.set('data', response); 
     )}; 
} 

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

Спасибо, Ractive - это потрясающе!

ответ

1

doThisThing представляется вашим уровнем данных и не должен знать ваш уровень пользовательского интерфейса. В противном случае вы рискуете тесно связать код.

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

// On the component 
oninit: function() { 
    var instance = this; 
    pingAnAPI().then(function(response){ 
    instance.set('data', response); 
    }); 
} 

// On your data layer 
pingAnAPI: function(){ 
    return $.get('path/to/endpoint'); 
} 

Другим способом вы можете сделать это, так как вы рассматриваете отдельные файлы, чтобы выйти из index.html и использовать файлы компонентов. Прочтите страницу component spec for authors для получения более подробной информации.

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

+0

Спасибо! В этом есть смысл. –

Смежные вопросы