Framework7 React #1162

Open
bencompton opened this Issue Oct 7, 2016 · 44 comments

Projects

None yet

10 participants

@bencompton

This is a (multiple allowed):

  • bug
  • enhancement
  • feature-discussion (RFC)

Other than a few small examples here and there on GitHub, there doesn't appear to be a React version of Framework7. My team and I have a good start on a React version of Framework7 that we're considering open sourcing at some point. Before we go through the work to do that, I'd like to make sure that we're not duplicating effort that anyone else is doing.

Our goal is to have a React framework that relies only on Framework7 HTML and LESS, and not its JavaScript--something similar to www.material-ui.com, except that supports both iOS and Material.

Does anyone have knowledge of a React version of Framework7 in development, or perhaps of any similar efforts?

@valnub
Collaborator
valnub commented Oct 7, 2016

On patreon.com it says that React support is planned but I wouldn't bet my money on it to be released anytime soon.

Pledging a few bucks on that site might speed up the process tho ;-)

Until then, why don't you share your experiences and your code on a Github repo? Could be interesting.

@bencompton

Thanks, I never saw that roadmap posted on patreon. I'm not sure how far along that effort is, but perhaps what I have so far can be a contribution. I'll be posting my code in a few weeks once I get a chance to clean and package it up and write docs.

@nolimits4web
Owner

@bencompton I will start to work on Vue.js integration/fork first. React integration won't be soon. So, of course, feel free to start your fork/integration and I can join to your project later

@slanska
slanska commented Oct 8, 2016

Vote for prioritized support of vue.js. Any specific plans/ideas for that? Have you seen https://github.com/lmk123/vue-framework7 ? (it is in Chinese, though)

@bencompton

Great to hear from you @nolimits4web. That works for me--I'll see if I can get an initial pull request ready in the coming weeks. To be clear, the React components I have at this time are far from the complete Framework7, but cover many of the essentials: views, pages & navbars with the animated transitions, tabbars, toolbars, side-panels, buttons, lists, etc.) and should be a good start. They were developed as requirements of another project, which is in its initial stages and will be an ongoing effort, and should continue to drive ongoing contributions for a while.

No Material support just yet, but I'd really like to have it soon. The LESS does such a good job of handling the differences that it shouldn't be too far off. In cases where the markup does differ (like with page and navbar nesting), I would imagine that the components should handle the rendering differences automatically. I've mused about perhaps having an overall F7 App component where Material vs. iOS, color themes, RTL, etc. are specified and propagated to child components via React context (similar to Material-UI's MuiThemeProvider), but I digress, and all of that can be a discussion for a different day.

@inoas
inoas commented Oct 8, 2016

ReactJS is really the way to go. Looking forward.
@nolimits4web could there be a split of the core project into the html+css and js parts?

@ZanderBrown
Collaborator

I would really be happy to see some TypeScript work as well.

@bencompton

@ZanderBrown, interesting that you should mention that, because the React components I have are actually all written in TypeScript. Not everyone is a fan of TypeScript, so that may or may not be a point of contention.

Indeed, @inoas, it would seem that a fundamental restructuring of some sort would be in order. I'd be interested if @nolimits4web had anything in mind at this point. It would seem that the LESS would shared, and perhaps some JavaScript would be shared as well. The examples, kitchen sink, and docs would seemingly need to be separate efforts. The argument could certainly be made to keep all of the docs in one place, perhaps with a tabbed interface like this.

@inoas
inoas commented Oct 8, 2016

I can't speak for anybody but my guess is, that for collaboration to work it would be easiest to have a repo for the HTML/CSS/LESS (or SCSS) stuff including assets such as icons and one repo that features the standard javascript, then maybe another that works with vue ... and then anyone could create something, say based on ReactJS or even ELM.

@valnub
Collaborator
valnub commented Oct 11, 2016

I also vote for React support and (optional) Typescript.

Haven't really heard much about vue.js to be honest..

@ZanderBrown
Collaborator

I think it would be easier to maintain if we used TypeScript and much like the use of less it doesn't mean people have to use it in their projects.

I have actually been working on porting dom7 with mixed results.

@nolimits4web
Owner

Something is already happening here https://github.com/nolimits4web/Framework7-Vue :)

@inoas
inoas commented Oct 16, 2016

I'd love to see Framework7-React and/or Framework7-Elm.
With those there would be a chance to pass beyond Ionic.

@bencompton

Great to see some progress in Vue! I'll take a look and see what cues I can pick up. ;)

framework7-react is also in progress: https://github.com/bencompton/framework7-react/tree/initial-code/. It leverages the framework7 NPM module for the LESS. I'm considering webpack for automatically creating a minimal CSS file for only the components being used, but am not sure whether or not to make the library be opinionated toward webpack (as opposed to browserify).

Currently working on getting a kitchen sink up and going. Will be creating issues and milestones soon to provide better visibility into progress.

Addressing earlier comments about TypeScript, it does use TypeScript, but compiles to ES5. The TypeScript compiler also generates .d.ts files, which will be in the NPM package along with the .js files (and LESS) and provide typings for TypeScript consumers. So, the NPM module will be consumable from TypeScript, ES5, ES6, CoffeeScript, etc.

@ZanderBrown
Collaborator

... and would make it MUCH easier to develop F7

@bicycleChen

Probably it should change on top of the agenda about the ajax pages? Cuz it not greatly work with react-router

@seme1
seme1 commented Oct 21, 2016

Will the Vue fork of F7 enable us eventually to use Weex for generating native UI components with the aid of Vue 2.0 ? http://alibaba.github.io/weex/index.html

@nolimits4web
Owner

@seme1 no, no weex here

@nolimits4web
Owner

Here is a small sneak peek of F7 Vue plugin and things I already successfully achieved:

  • Almost all F7 components are wrapped into Vue components which saves a lot of markup and also allows to differentiate some iOS/Material difference in layout automatically within components
  • And I finally implemented a bit different router that allows to load Vue components as pages. This was the hardest task. For this I added to native F7 router ability to pass page HTMElelement which is added to Dom and rendered by Vue and F7's router just do the animation stuff with further required pages callbacks and pages initialization. I believe same logic can be reused in React implementation
  • I also added a fix to F7 that allows to use same page structure with navbar inside of page, and it automatically moves it out of page and put to correct place if you use dynamicNavbar
  • Added Auto initialisation for F7, Views and some components configurable via properties so it's zero JS required for basic start
@slanska
slanska commented Oct 24, 2016

Sounds very exciting. Thanks a lot, Vladimir, for your great efforts and amazing library. Would you recommend to start using vue.js components for F7 or wait a bit for more maturity?
Бпасибо!

@bencompton

I got my initial branch in a stable state and merged it to master. Here's the kitchen sink: https://bencompton.github.io/framework7-react/kitchen-sink-ios/

There's not much in the kitchen sink for now, but there will be more coming soon. It doesn't yet show off all of the components currently in framework7-react, but it does demonstrate basic usage. More or less just a teaser at this point.

I'll post here again once I have more worth showing. Next on the agenda is Material support. Like the Vue version, I've been trying to make an API that abstracts away various DOM differences to make things simpler for the consumer. For example, a page and its navbar will automatically render appropriately for iOS and Material (navbar outside of the page and inside of the page respectively).

I do have more work to do to better align the API with framework7-vue. I'm pretty new to Vue, so I have some learning to do. One thing I'm not sure about is how much custom router code is appropriate for a React UI framework. I don't know about Vue, but the React community has pretty well settled on react-router (and react-router-redux), and you can see that is what I am using in the kitchen sink. I think this topic is certainly worth discussing further.

The kitchen sink also is not using a state management library (like Redux) for the sake of simplicity, but there will definitely need to be one or more examples with Redux. A fundamental design decision of this library is that all components are stateless and rely heavily on props. For example, you'll notice that the SidePanel component has an isOpen prop and relies on the consumer to provide the state management for whether or not the SidePanel should be open or not. Another example is the pages and navbars: the state for which direction they should be animating based on the last navigation action the user took, which the consumer is responsible for tracking and specifying (usually in the top-level Framework7App component). Given that Redux is a de-facto standard in the React community, I think stateless components are the best way to go, but this might be another topic worth discussing further.

Anyhow, the code is available for perusing in this repo and if anyone has any questions or feedback, feel free add an issue here: https://github.com/bencompton/framework7-react.

@nimo23
nimo23 commented Nov 6, 2016 edited

And what about Angular2-Support?

I like vue.js also, however, vue.js is not the only little framework out here and according to http://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html you can see, if you really need the fastest then you can go with inferno.js, monkberry.js or ractivejs.

I guess, Angular2/React is a lot more popular and if F7 chooses a framework then it should first provide Angular2/React-support.

I guess, there are no issues using f7 with angular2. However, f7 has no .d.ts-file (http://definitelytyped.org/). So supporting typescript needs to be the first way to support angular2. Another thing is, f7 has template7 so maybe its template engine can be extended to provide vue-like things as it is already available in f7.

@ZanderBrown
Collaborator

Can't remember where but I did find .d.ts somewhere however the design of Dom7 makes it tricky

@nimo23
nimo23 commented Nov 7, 2016

If a "f7.d.ts" exists, then it should be available in http://definitelytyped.org/.

@inoas
inoas commented Nov 7, 2016

@nimo23 there is not so much to gain from supporting Angular2 as there is Angular1+Ionic and Angular2+Ionic2. However there is nothing that works "mostly" out of the box for ReactJS. And ReactJS is getting traction https://www.quora.com/Is-React-killing-Angular and https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51#.84pwa0s51

Also the JSX Model of ReactJS works pretty well with Framework7 (stripped off its javascript) already.

@nimo23
nimo23 commented Nov 7, 2016 edited

as there is Angular1+Ionic and Angular2+Ionic2

Yes, you are right. I tried ionic 1 and found f7 a lot better and faster. I do not know if this is true with ionic 2. I will try.

But the question is:
Would f7 benefit from being converted to a typescript project? Bugs/Code Quality/Performance/Extendability/etc. I guess, yes. Iconic2 is written in typescript and there is a lot of gain for f7 also.

@inoas
inoas commented Nov 7, 2016

Can't say. Sure it would benefit from being rewritten into ELM, too ;-)
However I think it would benefit the most if there was a clear split between the HTML/CSS/SVG etc parts and the javascript libraries, so that those can be replaced easily.

@nimo23
nimo23 commented Nov 7, 2016 edited

In my opinion, before starting to make f7 more consumable by using vue.js, it should be ported to typescript. From typescript, developers can build view-templates/components as they like (angular2, react, vue.js, etc) more easily.

@nimo23
nimo23 commented Nov 7, 2016 edited

However I think it would benefit the most if there was a clear split between the HTML/CSS/SVG etc parts and the javascript libraries, so that those can be replaced easily.

I think the source code basis of f7 is already well splitted into "components". But the problem is, they are concatenated and only then it works. For sure, you can use the f7 build tool to have a smaller file with selected "components". However, would be better to use module loader and do something like this:

import {accordion} from accordion;

with code completion/css imports/tree shaking and the like.

There are a lot of benefits to use typescript for f7-project. The only thing where I am not sure is: performance. Would it be faster or slower? Does typescript produces faster, more optimized code as it is already the case? I dont know. Actually, F7 has really good performance.

@ZanderBrown
Collaborator

In theory the performance should be the same or better.
F7 in its current form is written much in the way TS out output it.

Porting F7 itself should be easy but in my experience Dom7 is much more problematic ($$ is both a Object and a Class)

@nimo23
nimo23 commented Nov 9, 2016 edited

but in my experience Dom7 is much more problematic

That's interesting. So the first step would be to abstract all Dom-Manipulation (of $$) within F7-Typescript?

@ZanderBrown
Collaborator

it think once a API compatible Dom7 could be developed in TypeScript the rest of F7 should follow quite easy

@inoas
inoas commented Dec 5, 2016

This is also related: https://ashleynolan.co.uk/blog/frontend-tooling-survey-2016-results#q12-knowledge-of-javascript-libraries-and-frameworks

ReactJS surpassed Angular 1 and Angular 2 is not picking up. Vue is rather small.

@ZanderBrown
Collaborator

I think porting to TypeScript would make it easier to create bindings for theses after all Angular 2 is written in TypeScript itself

@farskid
farskid commented Jan 24, 2017

@bencompton Are you still working on the React version? I vue.js even being pursued?? If so, i'd be happy to contribute, by the way, the kitchen sink link doesn't exist anymore

@bencompton

@farskid, the React version is still in development. Check out the Framework7 React repo home page for the latest news. Framework7 Vue is also in development. The Vue version is already published on NPM, but not yet at 1.0. We're hoping to have the React version caught up to the Vue version soon.

@ZanderBrown
Collaborator

i'm still on and off attempting a TypeScript port with thus far little success

@bencompton

@ZanderBrown, do you mean that you're rewriting Framework7 in TypeScript? Personally, I would be happy even if Framework7 just had TypeScript typings like a lot of other JavaScript libraries do. The Jade files in the Framework7 docs should actually have all of the data necessary (argument names + types, events, etc.) to be able to generate TypeScript typings automatically. If there were a gulp task parsing the Jade and spitting out typings, I would think that would be the easiest way to add TypeScript support to Framework7 and also keep the typings in sync with the framework in the future.

Framework7 React is now generating all of the React components automatically from the Framework7 Vue components. The Vue components all have props definitions so Vue can automatically validate props when consumed from JavaScript, but I am generating TypeScript interfaces from those automatically for the React components (the generated React components are all TypeScript). It would be great if Framework7 Vue had a gulp task that automatically generated typings for Framework7 Vue from these props.

I have thought about contributing auto-generated typings for both when I get time (which likely won't be for a while). If anyone wants to give it a shot, feel free.

@valnub
Collaborator
valnub commented Jan 24, 2017 edited

@farskid The Vue plugin is actually production ready afaik, see:

@valnub
Collaborator
valnub commented Jan 24, 2017

@bencompton Did you try these TypeScript definitions for F7? https://github.com/JasonKleban/Framework7.d.ts

@bencompton

@valnub - wow, I wasn't aware of those. Thanks for sharing!

@valnub
Collaborator
valnub commented Jan 24, 2017

@bencompton No problem, don't know how up-to-date these are tho

@ZanderBrown
Collaborator

If you have a way of generating .d.ts from jade feel free to share but as F7 is largely class based already i have been attempting to alter the code to be TS compliant.

The benefits being:

  • Built in tests
  • Readable Source Code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment