I decided to create my own and not to use a community package, because
1. it's straightforward
2. it's better integrated with our others libs such as EscapeActions
3. monitoring third-party packages evolutions (eg, CSS changes) is a
lot of work.
This is basically the same rationale than for our other generic UI
components such as the Popup/Popover.
This commit also slightly modify the general layout to remove
unnecessary wrapper DOM nodes.
This is an experiment about the implications of ES6 transpilation in
our code base.
We should also define a new ES6 style guide and a jsHint
configuration, for instance semi-colons are automatically inserted at
the end of lines, so we may remove them. We also need to figure which
ES6 features we want to use, currently I have followed Meteor-core
guidance which is reasonable.
Bower build process was sometimes unpredictable and had unspecified
dependencies (git) that caused bugs (eg #164, #172). Meteor packages
have better integration with the meteor build system and ensure
deterministic build, the downside being that we have to maintain
wrapper of JS package just for the purpose of publishing in
atmosphere. Others are also struggling with this, see for instance:
https://github.com/MeteorCommunity/discussions/issues/14
Hopefully we'll have a better solution one day (official browserify
integration? Who knows.)
As a side effect the new release of perfect-scrollbar breaks the
style, this will be fixed in a later commit.
Fixes#172
The new version of meteor speeds up the reload cycle, which is super
valuable during the development. I also removed the "imply-everything"
"meteor-platform" package in favor of a more fined-grained package
selection.
This version also introduces ES6 support with transparent babeljs
transpilation. Most features are enable (with the notable exception of
ES6 modules) and this commit started to use them in places where a XXX
comment suggested it.
Both the previous and the new value are completely arbitrary but some
users suggested that we reject names like "Li" for no good reason,
especially on private boards, cf #202.
Hopefully one day we'll have an administrator configuration panel.
Fixes#202Closes#210
Motivations:
* Iron-Router foces us to use Tracker.nonreactive black magic in order
to avoid un-necessary re-renders;
* There is a community consensus (supported by some MDG members) that
the flow-router API is easier to reason about;
* The useraccounts now supports flow router (that was a blocking
element when I considered the switch ~3months ago)
On the server we use the Picker router, as encouraged by the Kadira
team (which develop both Flow and Picker routers).
In the current state of things there are some bugs related to the
missing Loading architecure. Previously onRendered callback where
always called when the data the component needed was available, now
we have to handle this ourselves, which we will in a following commit.
This includes a security fix in mquandalle:bower, and a new package
for useraccounts iron-router templates which forced us to move some
configuration function calls.
We still miss some branding stuff, such as screenshots, icons, and a
description.
This commit also hides an option related to user permissions managment
in the sandstorm package.
Fixes the data context on the member popover in the details pane. Also
change the way Popover detect if the click is initiated from a parent
popover -- from reading Blaze context, to looking at the event target
parents.
Use a custom build of jquery-ui with only the plugins we need (instead
of including everything).
Fix a tricky bug of conflict between Blaze reactive updates and
jquery-ui (which caused cards to sometimes disappear).
New features:
- select all filtered cards
- assign or unassign a member to selected cards
- archive selected cards
This commit also fix the card sort indexes calculation when a multi-
selection is drag-dropped.
This commit also introduces a new CSSEvents object that is used to
abstract vendor specifics events related to CSS transitions and
animations.
Fixes#183.
Fixes#179.
The user is now able to upload an avatar, and pick one in a list.
This functionality should eventually be abstracted in a community
package but we still need to work on a great public API. We rely on
collectionFS to manage uploaded avatars. We also removed
bengott:avatar which was trying to solve the wrong problem (namely
displaying the avatar, which is as simple as displaying an image), and
not a avatar system as it should be.
Gravatar support is coming (back) soon. We may also want to have a
list of default fun avatars the user can choose instead of uploading
its own one.
This component wasn't used anymore. We'll probably need something like
that again in the future, but we'll try to use a generic component
from Atmosphere.
