You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Sam Ruby <ru...@intertwingly.net> on 2017/09/03 18:38:43 UTC

Roster on Vue (was: Do we care about the Facebook BSD+Patents decision?)

I've converted the roster tool to use Vue.js instead of React.js; I've
pushed the code to a branch where it can be evaluated prior to
deployment.

https://github.com/apache/whimsy/pull/38

I chose Vue based on the apparent size of the development community,
and the fact that its API is roughly a proper superset of React.js's.
In other words, it looks like you can do more with Vue than you can
with React, though for now, I've stuck with just using React like
functions.

Note: the API is not compatible, though most of the changes are to
wunderbar and ruby2js, so this work won't need to be redone for the
other tools.  Most of the remaining changes are mechanical.  Only two
logic changes were required.

See the pull request above for details.

- Sam Ruby

On Sat, Jul 15, 2017 at 7:48 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jul 15, 2017 at 2:46 PM, John D. Ament <jo...@apache.org> wrote:
>> I saw this coming for a few weeks.  Its been decided that Apache projects
>> can't use the Facebook BSD+Patents license.  Among the projects that use
>> this license include React.  Whimsy makes heavy use of React.  Do we care?
>> We're not creating releases.
>
> We have not created releases, and no releases are currently planned.
>
> React.js code is checked into the repository:
>
> https://github.com/apache/whimsy/tree/master/www/assets
>
> The following whimsy tools make use of React.js:
>
> * board/agenda/
> * roster/
> * secretary/workbench/
> * test/icla/
>
> One can't reasonably claim that this dependency is "optional".
>
> I also question whether it is possible to even have a "compile time
> dependency" in JavaScript.
>
> - - - -
>
> The least impact solution would be to argue the case that this is a
> system dependency.  That would involve removing it from the source
> tree, installing this source via other means (preferably via puppet,
> at worst case manually), and arranging for a httpd alias or equivalent
> to load this data from its location outside of the source tree.  Not
> sure what the impact would be to wunderbar which as currently coded
> would correctly determine that this code is not installed.
>
> The next least impact would be to convert the code to use something
> like preact (https://preactjs.com/) or inferno
> (https://infernojs.org/), both of which claim to have a compatible
> API.  (I have no experience with either).  While there have been legal
> cases as to whether APIs are subject to copyright, I don't believe
> this is an issue w.r.t. patents; which is the relevant concern with
> the Facebook "Additional Grant" with a termination clause.
>
> There may be other libraries that could be evaluated (e.g.,
> https://www.slant.co/topics/3790/~react-js-alternatives)
>
>> John
>
> - Sam Ruby

Re: Roster on Vue (was: Do we care about the Facebook BSD+Patents decision?)

Posted by Sam Ruby <ru...@intertwingly.net>.
On Sun, Sep 3, 2017 at 2:38 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> I've converted the roster tool to use Vue.js instead of React.js; I've
> pushed the code to a branch where it can be evaluated prior to
> deployment.
>
> https://github.com/apache/whimsy/pull/38
>
> I chose Vue based on the apparent size of the development community,
> and the fact that its API is roughly a proper superset of React.js's.
> In other words, it looks like you can do more with Vue than you can
> with React, though for now, I've stuck with just using React like
> functions.
>
> Note: the API is not compatible, though most of the changes are to
> wunderbar and ruby2js, so this work won't need to be redone for the
> other tools.  Most of the remaining changes are mechanical.  Only two
> logic changes were required.
>
> See the pull request above for details.

I've now merged this branch.

As mentioned above, the logic pretty much stayed the same.  Events are
what is most likely to be different.  So areas most likely to be
problems include: things not updating after an action, or focus not
being in the right place when you create a form.

Next tool to be converted would be the secretary's workbench, which
only uses React in four classes.  This, however, will involve mouse
and keyboard event handlers.

The test ICLA tool should be straightforward to convert.

The board agenda tool will be a massive undertaking.  Not because it
is particularly hard, but because of its size.

- Sam Ruby