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.
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!
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.
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.
Thanks! We're stoked with the great feedback this is getting.
We will have more docs + examples up in the coming weeks, aside from that we're currently using it in three commercial apps at Thinkmill so what's there is pretty solid.
The projects we're building with it include a Bitcoin wallet (built on BitcoinJS), a cinema voucher scanning app and another I unfortunately can't talk about yet. It's holding up really well across the different use cases and UI designs.
Thanks for letting me know. We haven't had a chance to test yet on a wide range of Android browsers, but it shouldn't be like that.
If you could open an issue on the GitHub project (http://github.com/JedWatson/touchstonejs) with details of your OS version and browser I'd really appreciate it!
You need a lot more control over how the views transition, pass state, etc. in order to create a native-feeling app.
The paradigm of links and parameters falls short, and eventually TouchstoneJS will exert a lot more control over the transitions. Right now we're using CSSTransitionGroup, but I expect we'll move to a JS-based transition method (possibly with tween-state) so you can do controlled or partial transitions (required for things like drawers or swipe-from-left to go back)
We have spent a lot of time looking at react-router though, and are using it on other projects, and are / will be borrowing quite a few things :)
The app framework is structured as a React mixin, everything else (lists, form controls, etc) is just React Components you can drop into your app. So for the most part how you structure your app is up to you (except for the scaffolding necessary for the view transitions). It's inspired by react-router (after the recent changes) in terms of getting out of your way.
Other than that, aside from needing some sort of compilation step for the JSX (our demo project uses browserify and gulp) the rest is up to you.
I haven't used Om or Reagent yet but I don't think there'd be anything preventing them from working with Touchstone.
Thanks! we're putting a lot of detail into the animations to make it feel as native as possible. The touch events too - you'll notice that if you touch a link, and move too far away, it'll un-hilight; then if you move back it activates again, just like on iOS. Or in a scrolling panel, scrolling cancels the touch event.
We've had a great experience building with React, and browserify - it keeps everything organised and modular, and is pretty much perfect for mobile app architecture.
I was just thinking a similar thing. If user agents have evolved to effectively become a way of saying "Our browser supports standards X" (where X is an awkward grouping based on which features vendors and browser versions originally supported the feature / standard), surely the ultimate solution is to provide a header enumerating support on a per-feature basis.
Obviously it would take a while for the standard to be adopted to the point where it was useful, but as a web developer I dream of a time when we receive a header that lists the supported features in the client (similar to the classnames modernizer adds to the document body, and probably eventually versioned) and no longer have to resort to either UA parsing OR javascript-based feature detection, both of which are hacks because this problem hasn't actually been solved properly at the standards level.