Integration with Meteor.js

[splendido]

Hi all,

I'd like to propose to start an official action for the integration of this awesome User Interface into the Meteor.js, the most popular full-stack JavaScript framework.

I'm starting off based on this very good attempt, about trying to put some order into the packages database for Meteor, started by @dandv. He also promoted an official integration for FontAwesome opening this issue on their official GitHub repository which so far had nothing to do with Meteor.

Since he wrote his proposal in a very clean wording, I ask you to read it carefully since it can be exactly the same for Semantic-UI.

At the moment there are at least five different packages all simply wrapping semantic source code.

@lumatijev, @nooitaf are the maintainer of the most stared packages: I hope they'll also agree about taking a single official action for this.

My proposal, if you agree, is as follows:

• verify whether the name 'semantic-ui' is still available for a new Meteor organization
• create the organization on meteor.com (it could be me if you wish, but not necessarily...)
• add @jlukic among the people belonging to the organization (requires him to create his own developer account) and possibly other people from both semantic-ui and meteor
• figure out the best pattern to follow the make it as easy as possible to publish the official wrapper package (possibly on the lines suggested by @dandv)
• publish the needed packages (css, less, sass, fonts, no fonts, etc...)
• contact all other developer who published similar packages and kindly ask to mark them as no more maintaned (so to have them disappearing from the list on Atmosphere)
• keep up the collaboration to maintain the published packages at best

Hope this make sense also to you...

Please let me know what do you think about this!

[lumatijev]

I like your idea and I'm willing to back it up.

[jlukic]

Thanks great write-up. Glad to see meteor integration kicking off. Let me know whatever assistance you need.

Once code starts forming I can add you to semantic-org and move over the repos.

I also encourage everyone to fill out the form in the readme to sign up for slack access. Will be useful for organizing.

[splendido]

Great! Good news then ;-)

what would you prefer as the Meteor organization name? 'semantic-org' or 'semantic-ui?

Consider that publishes packages come in the form 'organization:package_name'

so it could be something like:

• `semantic-org:semantic-ui
• semantic-org:semantic-ui-less
• etc.

or:

• semantic-ui:css
• semantic-ui:less
• etc.

That's mostly up to you I guess!

[jlukic]

We already have an organization set-up for Semantic-Org on GitHub. So I think it would make sense to keep it consistent on atmosphere. I'm not too familiar with naming conventions for Meteor packages. So whatever pattern you see most commonly used, I think is fine.

[splendido]

ok so I'd say lets go for semantic-org as the organization name.

Then it could be:

• semantic-org:ui
• semantic-org:ui-accordion
• semantic-org:ui-button
• etc.

But just in case we'll decide to public also single modules... otherwise semantic-org:ui, semantic-org:ui-less, etc. might be more than enough ;-)

Thoughts?

[nooitaf]

Just registered semantic as organization. semantic-ui is not possible because dashes are not allowed. Following iron:router's example i would suggest semantic:ui as package name.

• semantic:ui
• semantic:ui-button
• semantic:ui-accordion
• etc

As the semantic source uses less i would suggest dropping css and just use less by default. On deploy/running it will be converted to css anyway.

[jlukic]

These seems perfect. I think the ui- convention makes searching for components simpler.

[splendido]

Hi @nooitaf! So please add @jlukic, @lumatijev and @splendido to the organization

@jlukic please register yourself as a developer on meteor.com (top right corner...) possibly keeping your username ;-)

[nooitaf]

All added :)

[splendido]

well done! now please wait the others' consensus before publish anything. Lets not burn semantic:ui@1.0.0 with a mistaken publish ;-)

[lumatijev]

Agree with that. We should be careful with publishing since there is no way to fix mistake without increasing version number.

Should we all work in Semantic-Org's repositories? @jlukic Or personal repository and than publish in name of organization? I think it's better to work in same repository and have more branches for each package so that it can be easier to maintain?

[jlukic]

I've given invites to all those currently in conversation to join Semantic-Org. You should also have complete admin access to Semantic-UI-Meteor repo. I'll trust it to your organizing guidance. You should also have the ability to invite and add additional members to your team if you need to do so.

[nooitaf]

I am still trying to wrap my head around a good way/balance of usability and advanced settings. Sometimes you just want to drop in a front-end framework and go on. Having a lot of setting files would just complicate things. So maybe make semantic:ui just work out of the box and only if you add some special json/less at special positions (client) or have a config in javascript it would override stuff.

I agree that we should have a solid system (clear for the user) before we publish.

@jlukic nice :)

[lumatijev]

Maybe we could make semantic:ui to work out of the box as you said with no customization options. And lets say semantic:ui-custom or something like that with customization options?

[lumatijev]

Also, I agree that we should only use less source as you mentioned before.

[splendido]

Thanks @jlukic!

So welcome on board for the Meteor integration to all of us! Happy to be with you! ;-)

What do you think about bringing on the discussion as a first issue on the newly created Semantic-UI-Meteor?

[nooitaf]

@splendido go for it ;)

[dandv]

@splendido: Thanks for taking the initiative! I'm very glad to see my official integrations effort picking up speed!

I've also squatted the semanticui and semanticorg organization names, just in case, and added @jlukic, @splendido, @lumatijev and @nooitaf to them. But happy that we have the semantic namespace. Much better than the moment situation. (Who took that username?)

I'll let you guys run with this! Glad to have been of help.

[splendido]

Hey @dandv, it is thank to you if I started this! I completely agree with your points so far ;-)

...I've just updated the link as you asked.

We'd be happy to hear also your opinion about this discussion here

Tnx again, it's a pleasure to side you!

[ghost]

FYI - I noticed the comment about not doing a mistaken publish and burning a version number. In Meteor 0.9.3 they added special semver support for wrapped packages to allow you to keep the normal semver consistent with a release even if you did make a mistake :) For any sort of wrapped package you can set the version to "x.x.x_x".

You can read it on the blog at https://www.meteor.com/blog/2014/09/25/meteor-093-packaging-system-updates.

[splendido]

Yeah, that's true. Thanks for remembering us. The thing is, IMHO, there is no hurry at the moment so the best would be to have one single shot publication right at the first time to keep things as clean as possible.

I think it is not only about making a silly mistake you can revert with another publish like @1.0.0_1 but it is also about having reached an agreement on what to publish: CSS vs LESS, e.g.

I wouldn't publish a @1.0.0 with CSS files and then a @1.0.0_1 with LESS files for any reason ever ;-)

[zimme]

semantic:ui - everything that's necessary to get basic semantic-ui going. This should have less as dependency and use semantic-ui less source directly as @nooitaf said.

semantic:ui- - semantic-ui components/modules/whatever, should have semantic:ui as dependency

semantic:ui-less - should have weak dependency on semantic:ui and make the necessary setup if semantic:ui package is avaiable. This package should also have it's less files use .import.less to make sure it's not compiled with the less package automagically but only intended to be used by importing the files into your custom less files.

semantic:ui-less- - Same as above...

Something like this maybe?

[zimme]

Another approach is

semanticui:full semanticui:small semanticui:....

[splendido]

I like the idea to have a base package containing all .less.import files! Perhaps it would be better to call it semantic:src to keep semantic:ui as the main package with depends on the first one importing all source.

Then semantic:ui-<component> should imply the source and then have a number of week dependencies so to grant the correct import order of other components (in case this is necessary)

[zimme]

What i meant was

semantic:ui is depending on the less package and adds .less files that gets automagically compiled as css

then we would have semantic:ui-less which would have .import.less files instead

[lumatijev]

We don't need "-less" suffix if we will only work with less and not with css. It will be compiled to css anyways so there is no need to state less in package name. It will be easier to remember and more consistent to have only lets say semantic:ui as main package.

[lumatijev]

Keep it simple and as short as possible. I think that is important enough.

[splendido]

Ok, same thing. I'm sorry I got it wrong at the first read... :-(

[zimme]

When you add .import.less files the less package don't compile those files into css, and I know there are gonna be people who want to use the less files for all the mixins and stuff and not have it be automagically compiled but they will want to use the files for import into their own .less files.

@import "path/to/semantic.ui.files.import.less"

use mixins in their less code

[lumatijev]

That exactly what I said. Package will be less not css and it will depend on meteor less package. Maybe I confused you with "it will be compiled to css anyways". I was talking about meteor compiling less to css on run.

[lumatijev]

Oh sorry, I read your last comment once more and I see whats your point. You want all possible Semantic UI import files to be .import.less so people can use them before meteor compiles everything if I am correct?

[zimme]

Yes, in a semantic:ui-less package, this way people can choose exactly which less files they want in their applications with @import statments inside their .less files in the application.

Then you have the regular package semantic:ui where the regular .less files are automagically compiled into css on run/bundle =)

[lumatijev]

Agree on that.

[splendido]

May it be that ui-less can get someone confused and thinking ui is not based on less files? and then afrer adding ui-less gets disappointed because norhing is working as it was (wrongly) expected?

What do you think about less-src?

Name apart, I'd say we can start setting things up for this scenario.

Actually we were discussing about this on the other newer issue, lets repeat this proposal there @zimme!

Do you think we can get a list of files/components so to automatize the packages creation process? I'll have a look at the main repo...

[lumatijev]

Good point with confusing part! We will discuss names later for sure.

[dandv]

This may help - I've improved my Meteor packaging scripts to test and publish multiple packages out of one repo - https://github.com/RubaXa/Sortable/tree/dev/meteor

[unity3diy]

thanks :) :smile_cat:

[jlukic]

Hey its been a week, just want to check in with everyone. See what I can do to help get the ball moving again.

[dalgard]

:+1:

There are various packages with Semantic UI for Meteor but there's a big need for a canonical way of making customizations to the default styles of Semantic.

[PavanKu]

Guys, can anyone give some update about meteor integration? what is needed to make this fast?

[nooitaf]

@PavanKu Main Discussion is at https://github.com/Semantic-Org/Semantic-UI-Meteor/issues/1

@splendido did a good start on how to make publishing easy for the maintainer, but the 'theme/customization' issue is still unclear i think.

[dalgard]

The way I understand it, theming is mostly about overwriting variables in the LESS files of Semantic UI.

Does LESS have the same function as Sass does, where a variable can hold a default value, which may be overridden anywhere in the code, even before?

In that case, would it be a feasible way to go having a LESS file with variable overrides somewhere in app space and then compiling it before the LESS files in package space during the build?

I have no idea how or if the LESS module deals with uncompiled LESS code in packages (probably it doesn't), but maybe this should change in order to support our use case here.

[splendido]

We're waiting @jlukic to finish the integration PR. He already started to merge it manually on the meteor branch but I guess he's very busy these days with the 1.7.x releases going on...

After this, we should get official packages with plain CSS style files.

The problem with the LESS variable customization is better summarize in this post by Jack where it make clear the inheritance problems with LESS with the current structure of the project.

The good news might be that, once there will be a pacakge.js file on the master branch, if you download the Semantic bundle, customize it as you wish, and eventually build it, you can simply simlink the Semantic folder under your app's packages folder and your customization will be imported as a meteor package.

I'm more and more convinced that publishing different compiled themes or trying to find a way to let it easily customizable might be useless in view of this possibility.

Basically you could do something like this:

meteor create myApp
cd myApp
mkdir packages
cd packages
git clone https://github.com/Semantic-Org/Semantic-UI.git
cd Semantic-UI
....your customizations here ...
npm install
gulp install
cd ../../
meteor add semantic:ui
meteor

What do you think about this?

[serkandurusoy]

I spent the better half of this day trying to come up with a good strategy to include the official (as of yet) package and apply theming.

I certainly did want to avoid using gulp grunt bower etc and the likes. I love meteor for its simplicity and its isomorphic nature where I don't need to master different tools for different tasks and I love that it is itself perfectly capable of building various sources.

Meteor goes to great lengths to integrate everything into a single meteor command. No node install! No mongo install! No cordova tooling install! No android!... You see where I'm getting at.

If only we had means to meteor add themes, or perhaps a starter theme (css/less/sass) that we can copy over and begin hacking away...

You know what, I'm almost two years into meteor development, and I'm still dead-scared of node, npm, gulp, bower...

There... I said it...

;)

[jemgold]

@splendido is there anything we can do whilst waiting for #1607 to be merged to get Semantic UI working in Meteor with variables & customization etc?

[jlukic]

You can always drop in a zip file.

[splendido]

Hi @jongold, what do you mean with

with variables & customization etc? if you're thinking about a LESS version, feel free to investigate. Keep in mind that, from the previous discussions it seems hard to get a LESS version properly working because of a number of variables overwrites done on a component basis.

Unfortunately I'm not going to have time to look also into this: getting the canonical CSS packages (auto)published would be my personal goal... :(

Any news @jlukic on the merging process of meteor-integration? Please let us know if there's something you're not comfortable with, of if you simply don't have enough time to look at this now.

[serkandurusoy]

Is there a suggested way of using one of the pre-compiled templates to use as a base for a custom theme?

Of course I'm asking for a way of doing it within meteor, not by cloning the semantic-ui repo.

Basically, what next after meteor add nootifaf:semantic-ui?

I don't quite understand what zip file to drop in where.

[dalgard]

In the project I'm working on, I'm simply overriding whatever parts of the Semantic UI basic theme I don't like with simple CSS declarations. It is working okay, even if it's a bit bothersome and doesn't produce the nicest code...

[serkandurusoy]

a bit bothersome and doesn't produce the nicest code

nicely put :) Ok, I guess it at least seems to be the most convenient among the alternatives.