We are definitely on the same page. On Mon, Oct 15, 2018 at 2:06 PM Tibor Meller <tibor.mel...@gmail.com> wrote:
> @Shane It seems like we're agreed on this. :D > > On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller <tibor.mel...@gmail.com> > wrote: > > > Hi Guys, > > > > I think we could consider moving to ng bootstrap. It solves most of our > > problems and makes our code base cleaner easier to maintain. > > > > Here are some benefits I see: > > 1. we could eliminate jQuery from the code base > > Currently, we're using bootstrap but an implementation based on jQuery. > > Angular and jQuery doesn't build to live together. > > 2. NgBootstrap made to being used with Angular > > It uses Angular instead of hacking the rendering/dom manipulation with > > jQuery. > > 3. It contains a date and a time picker. > > It's easy to combine to a datetime picker. > > 4. No dependencies. > > By changing currently used bootstrap to NgBootstrap we could clear > jquery, > > moment, pickaday, pickaday-time libraries from our dependencies. > > > > Another huge advantage of NgBootstrap is that we don't have to rewrite > > anything we don't want to. Our UI already uses Bootstrap. > > > > What do you guys think? > > > > On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <n...@nickallen.org> wrote: > > > >> > Before making a decision on what's next, I'd to ask you a question. Is > >> it really > >> a priority and is it really worth the effort to touch our currently used > >> date picker component to get ~15% reduction in the bundle size by > removing > >> moment? > >> > >> As an aside, I think there is a greater benefit here too. We need to > make > >> a conscious effort to identify libraries that we are using that are > >> deprecated, lack community support, and are unlikely to be maintained > and > >> updated for security vulnerabilities. We need to actively identify and > >> replace those. > >> > >> > >> > >> > >> > >> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <ftamas.m...@gmail.com> > >> wrote: > >> > >> > I'd like to open a discussion about switching to a new date picker > >> library > >> > in the Metron Alerts UI regarding to the following: > >> > > >> > > >> > > >> > https://lists.apache.org/thread.html/2e4fafa4256ce14ebcd4433420974e24962884204418ade51f0e3bfb@%3Cdev.metron.apache.org%3E > >> > > >> > https://github.com/apache/metron/pull/1219#discussion_r223733562 > >> > > >> > A week ago, I opened a PR about removing moment.js from the code base > to > >> > decrease the size of the production javascript bundle. I could achieve > >> 15% > >> > loss in the final bundle size which is admittedly not a game changer > but > >> > still. Not to mention if we want to heavily rely on date manipulator > >> > functions in the future it's better to get rid of it at this early > >> stage. > >> > Go here <https://github.com/apache/metron/pull/1219> to read more > about > >> > the > >> > background and the results. I tried to provide as many details as I > >> could. > >> > > >> > So far, so good. But then I stumbled upon an obstacle, Pikaday > >> > <https://github.com/dbushell/Pikaday>. > >> > > >> > Before going further, let me thank Tibor Meller, Michael Miklavcic and > >> > Nicholas Allen for taking their time to go through my proposal to deal > >> with > >> > the aforementioned issue. At the end, we agreed on basically not going > >> with > >> > my temporary solution that intended to solve the related problems of > >> > Pikaday and we'd rather like to find and change for a better > >> alternative. > >> > > >> > To be fair, Pikaday is a pretty good date picker module, its only > >> problem > >> > is the moment dependency if it's installed via npm. But other than > >> that, it > >> > functions perfectly. Zero dependencies, small, etc. Long story short, > >> it's > >> > good for us unless we want to get rid of moment.js. > >> > > >> > Before making a decision on what's next, I'd to ask you a question. Is > >> it > >> > really a priority and is it really worth the effort to touch our > >> currently > >> > used date picker component to get ~15% reduction in the bundle size by > >> > removing moment? > >> > > >> > I'm asking it because if we want to do so, considering that it's a > huge > >> > topic, the following questions might come up: > >> > > >> > *A: What component do we want to use instead of Pikaday?* > >> > > >> > I'm not satisfied with the alternative individual solutions out there > on > >> > npm. I'd rather pick a component library like the angular port of > >> Bootstrap > >> > <https://ng-bootstrap.github.io/#/home> or the angular material > library > >> > <https://material.angular.io/>. Both of them have a date picker > >> component > >> > and many other components to rely on and reuse throughout the Metron > >> app. > >> > > >> > *B: What component library do we want to use?* > >> > > >> > Introducing a new component library requires a lot of research and > there > >> > are many things we have to agreed on. Since it's a long term plan > >> because > >> > it would be great to use it consistently instead of picking a new one > a > >> few > >> > months later just because we chose wrongly. > >> > > >> > *C: What about the jQuery version of Bootstrap?* > >> > > >> > So basically we already have a component library and we still use it > but > >> > we're also planning to replace it with another or the angular port at > >> least > >> > to get the most out of the angular rendering engine. Since it uses > >> jquery, > >> > it's much less performant than a port written in Angular. > >> > And I think it's a bad idea to introduce a new one and use multiple > >> > component libraries within one project. > >> > We can also pick the date picker component from the jQuery Bootstrap > >> but, > >> > again, it's not as efficient as the angular port so it seems to be > >> > beneficial to replace it with something else. > >> > > >> > What do you think, guys? > >> > > >> > Thanks, > >> > Tamas > >> > > >> > > >
