You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would replace the geocoder param passed from table/table.js to various child views (that need to know the isGeocoding() state).
Also on the subject of models, IMHO, we would be better of to keep all models that represent a concept/API endpoint in one place, e.g. models/ (since that seems to be the commonplace). @CartoDB/frontend what do you think about moving them to that directory than have them spread out in various locations (e.g. move from common/background_polling to models/?
The text was updated successfully, but these errors were encountered:
There has been no activity on this issue for more several months. We are closing it. If you think this still needs to be addressed please open a new issue.
Right now we some models for the same imports endpoint:
cdb.admin.Import
(will be located inmodels/import.js
after the removal of old modals Remove old, unused modals code #5068)common/background_polling/models/import_model.js
cdb.admin.Geocoding
common/background_polling/models/geocoding_model.js
geocoder
param passed from table/table.js to various child views (that need to know theisGeocoding()
state).Also on the subject of models, IMHO, we would be better of to keep all models that represent a concept/API endpoint in one place, e.g.
models/
(since that seems to be the commonplace). @CartoDB/frontend what do you think about moving them to that directory than have them spread out in various locations (e.g. move fromcommon/background_polling
tomodels/
?The text was updated successfully, but these errors were encountered: