jed_watson

I phrased it badly - I meant the modal scroll handling that was implemented hasn't worked out well, no red flags for React here. position: fixed is a more robust way of positioning modals, the current version watches the scroll event and updates the modal's position which is pretty janky; and it does some not-great things manipulating overflow on the body too, which causes the bug mentioned. We'll be fixing that in the next release.

Not sure if you saw my other comment below but this is a major goal for us with Elemental. We're not there today, because we're working through the best way to componentize the CSS for each module while retaining a common base for variables & customisation (i.e themes).

The most likely outcome will be to go with the "css in components" approach (w/ Radium, I expect) and maybe a base / "foundational" optional stylesheet for typography / etc. Still working it out though - all today's viable approaches have lots of pros and cons.

Thanks for pointing that out - webre using react-router and it works locally, not sure why hosting on github pages breaks it. Will check it out.

It means we've borrowed the css directly from Bootstrap for the grid (as well as some variables and mixins) so, aside from giving credit, if you are familiar with the bootstrap grid it should be easy to get up and running with Elemental.

We're actually developing it first and foremost for use in Keystone's Admin UI - we needed a robust and flexible css + component library for that, which users could extend & build plugins on, so we started building one.

Elemental UI is a competitor, sort of, I guess. But it's not a zero-sum game, and we've learned (and borrowed) a lot from Bootstrap.

More specifically, we're not porting Bootstrap to React but building React-specific components from scratch to fill the same gaps.

Something in particular we're focusing on is building a modular IU toolkit - so you could use all of Elemental, or just our select component / buttons / date picker / etc; all of which would be available as standalone packages on npm, but can leverage a consistent thumbing system and play nicely together.

(And yes - we'll fix that modal issue soon with a pure css approach; a community member wanted to implement it with JavaScript but it hasn't worked out well)

Thanks! We're porting their grid system manually at the moment, the foundations don't really change much and we're quite selective about what's being ported.

We're actually experimenting with deprecating access to classes (i.e exposing components rather than class names as the public API) - will be interesting to see how popular that approach is.

2. LESS has been our favourite pre-processor for a white but we're finding it doesn't play well with packaging modular components on npm. Some real limitations around the @import logic, and the core team refuse to make it to work with node-style require path resolution which is disappointing.

From here I think it's more likely we go with the "styles in components" approach (via Radium or similar) and make variables / themeing available via context. Much easier to package & use "out of the box". Might keep a "base" css include though, or possibly use the Bootstrap 4 "Reboot". The distinction between, and best way to package, component styles and page styles is something we're putting a lot of thought into!

Thanks! that's really great to hear.

I'm not familiar with the benefits of HostGator but how is this better than spinning up a free Heroku dyno to serve your node.js app?

That's also a very effective solution for low-traffic sites with a modest amount of host-side processing and more than enough for one sale a minute.

It's got great options for 3rd-party service integration too (e.g. free MongoDB hosting for < 512mb with MongoLab), and a very node.js friendly environment / deployment workflow.

Not trolling, genuinely curious what the benefit of this would be as an alternative.

Yes - we've already got it working with iOS and android using Cordova, Windows should be straight-forward as well.

There's a Cordova project that builds for iOS in the sample project if you're interested.

We won't be limiting the look to iOS 8, we just started there because it's the platform we're developing some commercial apps for using TouchstoneJS at the moment. At least two of them will end up on Android as well, so we'll get to that.

Down the track it will including a theme capability and a more Android-friendly UI style, I'll add something to the roadmap to make this clearer.