From dev-return-4041-archive-asf-public=cust-asf.ponee.io@royale.apache.org Sat Apr 14 02:58:53 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8BBA6180627 for ; Sat, 14 Apr 2018 02:58:52 +0200 (CEST) Received: (qmail 88505 invoked by uid 500); 14 Apr 2018 00:58:51 -0000 Mailing-List: contact dev-help@royale.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@royale.apache.org Delivered-To: mailing list dev@royale.apache.org Received: (qmail 88489 invoked by uid 99); 14 Apr 2018 00:58:50 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Apr 2018 00:58:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 2D82B1804F8 for ; Sat, 14 Apr 2018 00:58:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.228 X-Spam-Level: ** X-Spam-Status: No, score=2.228 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id mhfzOchk5cJ0 for ; Sat, 14 Apr 2018 00:58:48 +0000 (UTC) Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com [74.125.82.172]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 5A45A5F398 for ; Sat, 14 Apr 2018 00:58:47 +0000 (UTC) Received: by mail-ot0-f172.google.com with SMTP id y46-v6so11781145otd.4 for ; Fri, 13 Apr 2018 17:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=esz74YNhkt8VRi1Dneo0SyiAJtpjaqsRIEHXM7O34pY=; b=Iqxm9kmzp/TZ6NcwNqWZT1D/3JYlnQyjIrtZO/Bz9MIYcsx63Bk+1qqtCdBI7udZi8 /YF9Hnx7fcnNZZQZLlaFJIZY2agx4vYoKbxBqWdyQsMHSp5ARyaBJKx4eUBaZ14sTNjn RTOD/p9614cdNslB9q/dz9LDZtYI6KYN/vUHFjglBPOpHl/WFTmcc5sbrOWVScfC83sf fh5h1qBkpLMgtTG/Ytge73vpyJ7V2OyEncfa+PEBYOpAGH58tOnaFQuVYTyGLzIJR1L9 41qSojyHdXC08WxHGMjbNG1gYIOlO8RK562a7AAiXhhVcD509YeM3mtktcx9a6vtgEI6 tlRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=esz74YNhkt8VRi1Dneo0SyiAJtpjaqsRIEHXM7O34pY=; b=KDECHVn1L6v6OBXbOue0qODgGJJXjMhB6NYrV0c2JaoRWiiVBZEk8/UVYBGtcTR0Id kHwJLu65JDVsk9Aa/UX+/XhGtX2CTunB+fzwSqqQ+5O4JzZisULLCIbi535Y1KdTmSiq yZO08xZJIzmrpeZjcMid/pN9ph1VqHOjX1UqZSpghsBUc/ZrZMOuElvqbQJJmSQlrRK8 2YFYV9xih2h4eSBlbLGOQM2UL7RK6nHrkmXqUiJVT/Aska0Qy+D7kqHw6E5+Ad7J6dsa OinYQ249qF5dJmErCyzb76HAj3RT1A8LwXy3kADBMOh5IWwj22I6pv2AT6Hzt/CBSpqj alHQ== X-Gm-Message-State: ALQs6tAMnszhCgYdSH/hXqXWDs1n4RgZuo8k8hT74UHw1bfEvVA6MJYR iMKZDwrpnRwopUZX/2kC2SCO4ErfQSh2zFPHm7/3oQ== X-Google-Smtp-Source: AIpwx496sbFGAyVtmGxzHEjW6u+NXANHkqx6FWbDCyeyrepigw+IbvgzdcQxB+5oM1xhsPZhlrpG6GTDFUqyhHCjygg= X-Received: by 2002:a9d:233b:: with SMTP id j56-v6mr935330otb.318.1523667525805; Fri, 13 Apr 2018 17:58:45 -0700 (PDT) MIME-Version: 1.0 Sender: carlos.rovira@gmail.com Received: by 2002:a9d:114:0:0:0:0:0 with HTTP; Fri, 13 Apr 2018 17:58:25 -0700 (PDT) In-Reply-To: References: <152329931249.10784.14497557385943417051@gitbox.apache.org> <20180409184152.8D1C280A64@gitbox.apache.org> <6847B4BB-C287-4A24-BD8E-D5345C93ED51@gmail.com> <7DE5F977-9A5D-48F0-B7DF-076A020CA288@gmail.com> From: Carlos Rovira Date: Sat, 14 Apr 2018 02:58:25 +0200 X-Google-Sender-Auth: paDkAJrnBf-VfBSRfZ5kME7GRXk Message-ID: Subject: Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles To: dev@royale.apache.org Content-Type: multipart/alternative; boundary="000000000000a1aad40569c47d09" --000000000000a1aad40569c47d09 Content-Type: text/plain; charset="UTF-8" Hi Alex, just studied you changes and want to ask you a few things: 1) Why className and classLists methods must remain unsynced? I think this is not necessary and seems to me a bit unnatural since when I add styles though classList in a element this makes the internal list changed, and if I then do "trace(element.className)" it will report the updated list...so I think both are synced by default 2) Now Button has two new methods that must make various operations with arrays (join, push, splice...), this means in almost all jewel components override at least computeFinalClassNames and insert new custom methods for add/toggle/remove and each one will make various operations: in the case of toggle will do a push or splice and then the normal classList toggle operation. 3) we are introducing a new array property per component to store what classList already do So for me we are introducing lots of complexity, with more code splitter in every class, each one with more operations of array operations that finaly makes the same call I did. And generating complexity since className should be used by users only at init time and then use the rest of classList apis... The only difference for me is that you want to avoid the classList initial add method that in most of the cases will add from 1 or 2 classes and up to 3-4-5. I think normal components would have 3 on average... This related to lots of sites saying "use classList instead of className" and frameworks like MDL that are based only on classList , and all jsperfs (that although are not reflecting our concrete use case and use of classList, I think are completely valid on essence) makes me think about how we have such different visions. So I must to say that as much as I want to see the advantages the approaches do not convince me... for me is more simple that all of that. 1) I think people have the APIs (className and classList) and can/will do what they want, although we say "use className only at init time". 2) I think we should have the most easy way to modify since browsers are takin care of internal apis performance (or at least I'm confident with that, like I was confident on flash player performance) 3) I don't like to introduce lots of code when maybe the basic usage of classList can be even more efficient. I give various jsperf studies out there but both Harbs and you didn't show me anyone that shows className as a better option. 4) If we are introducing such complexity, wouldn't be better to remove completely classList and end that code with the new array property and array operations? I think it will be more performant and will remove complexity. 5) If I use that solution for jewel, I should introduce some intermediate class between UIBase and a Jewel Component where I can proxy all that methods that are now in button to avoid replicate in all jewel components. And by doing that, as I said before, I'll prefer to remove that complexity and go for simple classList manipulation since is the same that MDL (to name a concrete and successful project that renders and performs magnificent) does [1] (I put button example just as an example since there's lots more) Sincerily, I'm not convinced with the results exposed here, and I was always thinking that I was not seeing something evident, but now I'm even more convinced that we should use classList without any rejection. Even for the use of className in MXML, is ok since I proved you can transform it without problem getting the string, splitting and introducing in the classList, and then opertating with is when needed without any performance significant problem. For me is more problematic all the code we want to introduce to avoid possible performance problems that I and many others don't see and that main web projects actually don't see and are used all over the web. We should not be different in something that other has already adopted, and if people is using it, is because the browsers, the standards and all the web wants all people using it, and for me is what happen with classList. in resume. I still don't want to make this discussion longer. I think we have different opinions on this particular subject and the greatness of royale is that it doesn't mind since if you and Harbs are betting for className, we can remain Basic with the initial use (or the current one). For Jewel, I can bet for the same method MDL uses with classList and as I must to refactor half of the Jewel components to extend from UIBase directly instead of Basic components counterparts, I can put a JewelUIBase piece between that uses classList in the way Jewel need. In fact Jewel, and any of the modern UI sets (Semantic, MDL, Bootstrap, ...) depends heavily in class selector assignation, hence the use of classList as a general rule. So I think is natural to have this marked differentiation, while in Basic we should not expect people wants to deal with class selectors in a heavy use. Maybe I can wrong, but sincerely, if so I can't see where, but I firmly believe in that, and for me is a clear definition of Jewel needs. Thoughts? [1] https://github.com/google/material-design-lite/blob/mdl- 1.x/src/button/button.js --000000000000a1aad40569c47d09--