There are detailed instructions on theming on the traditional Semantic UI, but the equivalent section is missing from the Semantic UI React site. Does that mean that it doesn't support theming or can you possibly use the traditional Semantic UI's approach to theming?
I know that some folks in the React world advocate for not using CSS and instead doing you styling programmatically as part of your component design. What's the Semantic UI React philosophy on that?
The theming part is "missing" in the react semantic ui docs, but thats on purpose.
Thats the way I did it:
Install the full Semantic UI package. Semantic UI includes Gulp build
tools so your project can preserve its own theme changes, allowing you
to customise the style variables.
Detailed documentation on theming in Semantic UI is provided here.
$ npm install semantic-ui --save-dev
After building the project with Gulp, you'll need to include the
minified CSS file in your index.js file:
import '../semantic/dist/semantic.min.css';
via: https://react.semantic-ui.com/usage#semantic-ui-package
There are already different ui-frameworks with a more "react" approach. IMHO what semantic ui (react) does is the best real-live solution so far...
One of the questions is "Where should we put Semantic UI inside your project?" and you should put src/semantic which overwrites the default.
Related
For some reason I no longer see the OPTIONS menu item when I am on the Builder tab for a template. I have not needed to access this tab for months so I am not aware of when it went missing. I am on Sitecore 8.2 (rev. 160729). I have not installed any new modules or packages recently so I do not think its related to that. Has anyone experienced this behavior?
Based on our comments, the only reason why the option tab is not appearing is because of the css styling display:none.
This is not caused by Sitecore css or js files but rather a custom implementation. I would suggest to check your css files or even JavaScript files.
It might also be the case that there was a development to hide or show certain tabs in the ribbon which in brief may be due to custom development of ribbons or even commands. So, you may check the different commands or ribbons implemented.
Finally, which I think may be of least importance, is the development of SPEAK UI. It might be that you have a 3rd party module which is injecting the styling or a module implemented.
I am trying to move an application from using tornado templates (to be more accurate, it's jinja with an adapter) to ember.js.
It is my understanding that ember.js has very strong opinions on how to compose the final rendered product. In practice, it seems that the whole application must be generated from ember templates on the client side. The server side just provides data in REST format.
Is it possible to have ember work and take control only on some parts of a page that is mostly rendered by tornado templates (a la jquery plugins), or do I have to completely switch to ember?
Welcome, glad you're looking hard at Ember! You're right, Ember has definite opinions on how things should work :-) Despite that, it is indeed doable to migrate over in chunks.
You have a few options on how to handle this.
1. Build out from a single div on a page
You can see this in action on the builds page on the main Ember site (which is a small Ember app). Source for it is available here: https://github.com/ember-learn/builds/
Of interest is the fact that you can define the rootElement that you want Ember to render in to (see https://github.com/ember-learn/builds/blob/master/app/app.js although we should actually move that line to the config file). Once you have Ember on the page it is then possible to have it both interact with external Javascript or to have external Javascript call in as needed.
2. Sprinkle Ember components on to a page
If you need Ember to control multiple parts of the same page, you may want to look at https://github.com/mitchlloyd/ember-islands That addon is designed to work with server-rendered pages, so may not fit your setup. But it's another example of how to refactor in.
3. Use the new GlimmerJS (alpha)
You could also start refactoring into Ember using the newly announced GlimmerJS. The goal for this library is to allow folks to sprinkle in Ember and then as they need page routing and other aspects of Ember, allow them to switch over. So it may fit what you are after.
Note however that the GlimmerJS layer (on top of the Glimmer vm) is still quite new. What is there works well, but much of the Ember polish is still being added. So shipping to production could take some work ...
hey guys I am totally blown away by the power of clean semantic mark-up.My Question is that can i just use the UI components of fundation with Neat? has anyone tried it yet?
thanks.
You absolutely could, though it would muddy your semantic mark-up and bloat your app some. Not sure if you're using Rails, but: How can I use two css frameworks in one rails app? (Using foundation and bourbon neat on same app)
Have you taken a look at refills? It provides you with a lot of pre-packaged UI components built on top of the bourbon/neat/bitters stack that you can easily tinker with to fit your needs.
I'm trying to optimize my company's application.
Tha architecture at this time is composed of different folders (inside common folder) for different sections of the app (for example Managing Bills, Managing Canteen, Managing Events etc etc).
Every js and css are included in the first page of the application (login.html) because I'm using the simple page template of jQuery Mobile.
Now I'm considering to add some other components to make the app easier to mantain and maybe speed it a bit.
What do you think about:
RequireJS to divide each section in a module so i can load only the javascript of a particular module at run-time instead of loading within login.html
Inline #imports for CSS files to produce single composite CSS
uglify.js to Minimize file sizes
Handlebars.js to realize fragments of html reusable
Do you think is a good way of work for an application that will become greater by adding new sections?
Do you think of other tools?
Thank you
This is a very broad question. I think you're on the right track... I'll list some libraries that could be worth trying:
Require.js - Will give you the ability to have 'modules' and dynamically determine and load dependancies. Alternatively some people prefer patterns such as the Revealing Module Pattern, jQuery Plugin Style or Common JS style modules. For what it's worth I recommend Require.js.
Bower is a package manager, you can use it to bower install [package]. They have a lot of packages here and you can also link it to your own repo. This could be helpful for managing dependancies.
Uglify.js and Google Closure Compiler are both good for minifying your code. Remember that some minification configurations such as advance mode could break your code. Run tests against the minified version of your source code.
QUnit is good for doing JavaScript unit tests. There are many other alternatives like Jasmine, which is what the Cordova guys use.
Lodash is another (faster) implementation of underscore.js that will provide a lot of utility methods for working wit arrays, objects, functions, etc. It also includes templating support. There's a good talk by the author here.
There a MV* JavaScript frameworks that could help more than jQuery (DOM+AJAX+Animations) or jQuery Mobile (Mostly UI) such as: Dojo, AngularJS, Backbone and Ember.js.
For UI you may want to checkout Adobe's topcoat repository and website. There's also Twitter Bootstrap and Foundation which allow you do to responsive design out of the box. If you're set on jQuery Mobile I personally like this Flat theme.
JSDoc and YUIDoc are good alternatives for documenting your JavaScript code.
I have no idea how many of those tools will interact inside Worklight Applications. It should be fine, since Worklight doesn't impose a certain set of JavaScript libraries you have to use. However, I haven't personally tried most of them inside Worklight Applications.
I can understand needing some abstraction layer for common operations like retrieving DOM elements, attribute manipulation, etc., but jQuery is a pretty massive library that seems like a lot of overkill for Ember.
After looking through the source code, there are only about 30 or so uses of jQuery in Ember and it looks like the majority of jQuery usage is simple selector calls, some events, and some DOM traversal.
Ember.$(rootElement).off('.ember', '**').removeClass('ember-application');
...
elem = this.$();
...
this.$().appendTo(target);
...
Ember.$(window).on('hashchange.ember-location-'+guid, function() {
etc.
Are there any other reasons Ember requires jQuery for every application?
Could these few uses be embedded into Ember and jQuery removed as a dependency?
The question was extremely well explained by Tom Dale (Ember Core Developer).
Essentially he says:
Ember.js requires jQuery for two reasons:
We rely on it heavily in the Ember/Handlebars integration for inserting and modifying DOM elements. I personally am not interested
in dealing with cross-browser DOM manipulation bugs, but the jQuery
team excels at it.
By having a standard DOM manipulation library in jQuery, developers can move between different Ember.js apps and rely on the fact that
they have a battle-tested, cross-platform library underneath them.
If you are concerned about size, I'd recommend investigating the new
jQuery 2.0, which has the ability to do custom builds without features
such as animation.
Makes a lot of sense to me.
Update:
Recently Erik Bryn (Ember Core Developer too) wrote a very interesting comment about the framework and mentioned the state of the art of jQuery usage in Ember projects.
Pasting the comment:
It's a common misconception that Ember.js is monolithic. I can assure
you that isn't actually true. You can pick and choose the parts of
Ember that you want or need (for example, the router is totally
optional). Our build tools even support picking and choosing which
packages you want. You can use it today without jQuery (you will need
to shim and have an event delegation library, or even easier use a
super-lightweight custom jQuery build).
Only Ember's view layer depends on jQuery. It was used more heavily historically than it is now. In the future, we could as you suggest, roll functionality into Ember itself, although we do not want to maintain cross-browser compatibility in Ember that jQuery is already taking care of. Another path, with jQuery 2.0, would be a way to create trimmer build of jQuery containing just the portions that Ember uses.
If there are no-compromise ways to replace instances of jQuery usage in Ember core, you should propose the changes as issues on GitHub.