Filters sidebar

[Crashillo]

Currently there are several implementations of the filters sidebar along Gobierto app. They're all slightly differents each other, but some of them can be merged.

• investments
• data
• visualizations
• documents (engine)

The best approach due to its isolation, loose coupling, high cohesion and simplicity is at vue/mixins (code will be brought to gobierto base shortly).

Regarding gobierto-data the refactor will be quite simple, as such module was using a needless property there (store)

Regarding gobierto-investments will be little trickier, as the store property (perhaps no longer necessary) is pretty binded all through the module

Regarding gobierto-visualizations will require a further look, as the filters trigger events also, in order to make dc.js listening such events

Once we have some shared, working code, it could be wrapped into a Vue component to create the default filters sidebar when no specific HTML/CSS is required (currently you choose what inner components will render)

Related to https://github.com/PopulateTools/issues/issues/1208

[Crashillo]

The wrapper component is done in #3934
Modules to update:

• documents
• data Filter supercomponent: gobierto data #3936
• investments
• visualizations

[Crashillo]

Since the wrapper component also deal with the routes, the gobierto_data implementation won't be so straightforward as initially was.

[furilo]

Should this be done?

[Crashillo]

After analysis this, my thoughts:

• data module requires an enhancement for the route handling, as we agree in https://github.com/PopulateTools/issues/issues/1208
• investments wouldn't be over complicated, it requires quite changes, though, but I think it's manageable
• visualizations is the trickiest, imho: quite code updates as investments, but the key difference is that would be more difficult to me since I didn't do this module, however, there are enough backend tests to ensure the proper work.

Answering your question, this is a regular technical debt: should be done? any enhancements, refactor, code cleaning is always welcome. does it worth? as long as there is any stuff to improve in the modules, we can take that chance. Since you assign me some issues for mataró, I can do them, refrsh my mind with that code, and apply the mentioned refactor.

[furilo]

OK finish first Mataró El mié, 18 sept 2024 a las 11:41, Hugoren Martinako (< ***@***.***>) escribió:

…

After analysis this, my thoughts: - *data* module requires an enhancement for the route handling, as we agree in PopulateTools/issues#1208 <PopulateTools/issues#1208> - *investments* wouldn't be over complicated, it requires quite changes, though, but I think it's manageable - *visualizations* is the trickiest, imho: quite code updates as investments, but the key difference is that would be more difficult to me since I didn't do this module, however, there are enough backend tests to ensure the proper work. Answering your question, this is a regular technical debt: should be done? any enhancements, refactor, code cleaning is always welcome. does it worth? as long as there is any stuff to improve in the modules, we can take that chance. Since you assign me some issues for mataró, I can do them, refrsh my mind with that code, and apply the mentioned refactor. — Reply to this email directly, view it on GitHub <#3928 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGBJBMQP5OGJKP4L2DSKLZXFDE3AVCNFSM6AAAAABONDS4ISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJXHE4DOMBSG4> . You are receiving this because you commented.Message ID: ***@***.***>

-- http://twitter.com/alvaro_ortiz_es http://www.furilo.com