I'm joining Meteor as Developer Evangelist!

alawi · October 31, 2019, 11:13am

Wow, bkmarke looks impressive!

I’ve not used MUI react yet but I’ve used FM7 and I want to experiment with Ionic 4 (will share with the community when I get something going), I’m still unable to find good samples for Ionic 4 since it is relatively new so I’m not sure how accurate their claim is about being mobile optimized. I might be a good step for Meteor and maybe supporting the react/vue native frameworks and cordova is a better approach, but what also got me interested in ionic 4 is that it is based on web components which might have longer lifespan that other frameworks. I just wanted to point out that there might be potential of integration with Meteor and it also good to keep an eye on that community.

Sorry for going off on a tangent.

illustreets · October 31, 2019, 12:04pm

Congratulations @filipenevola! This is the best news in a while. I’m so positive now about the future of Meteor.

martineboh · October 31, 2019, 12:19pm

Congratulations @filipenevola. We’re witnessing something welcoming, game-changing, groundbreaking and heartwarming in the Meteor community - and I am very happy with all latest development (Tiny acquisition) and I wanna really say a big thankful for all those who stood and continued supporting Meteor and the community.

rjdavid · October 31, 2019, 2:39pm

Great to see a familiar name to be working with Meteor. Congrats @filipenevola

By the way, I just sent this to my team earlier today

filipenevola · October 31, 2019, 3:16pm

Great @rjdavid.

Thanks @illustreets and @martineboh. We are going to make great things together Meteor community is incredible.

victorfds · October 31, 2019, 4:00pm

Congratulations, @filipenevola, I’m so glad for you.
Brazilian’s developers community is growing up to worldwide.

jirimusil · October 31, 2019, 5:16pm

Congratz @filipenevola, happy to see such move…

stolinski · October 31, 2019, 8:13pm

This is amazing! Congratulations.

Saksi · October 31, 2019, 8:46pm

Congratulations @filipenevola. Really good news! Can’t wait to see what magics you can do for the community

orloff · November 1, 2019, 6:22am

Meteor community is unique and very active, looks promising!

jorgeer · November 1, 2019, 10:29am

Great to hear! You are very much needed here @filipenevola Looking forward to seeing where we are going next

seba · November 4, 2019, 11:22am

Congrats! Glad to see Tiny taking its first actions.

I can think of about 57 of those

filipenevola · November 5, 2019, 11:25am

Yeah, I know, we are going to improve this together. Please list here the ones that you think are still valid if possible starting from the most important ones.

filipenevola · November 5, 2019, 12:49pm

storyteller · November 5, 2019, 2:11pm

My top 2 are:

github.com/meteor/react-packages

Optimized useTracker hook

meteor:devel ← CaptainN:hooks-plus-ultra

opened 04:07PM - 26 Jul 19 UTC

CaptainN

+1503 -240

This PR is a roundup of the discussion (and builds on the work) in #262 and #271…, and supersedes: #242, #252, #256, #263, #266, #267, #268. It does the following: - Create a base hook, `useTracker` to for use as an alternative to withTracker in hooks based projects. Rewrites `withTracker` on top of `useTracker` (issues #256, #252, #242 / PR #261) - Updates docs! - Removes deprecated createContainer. - Above #262, this PR retains the synchronous rendering behavior in `withTracker` and in `useTracker` if no deps are specified, but also allows asynchronous reactivity after `firstRun` if deps are supplied, and properly responds to deps changes. This implementation is [compatible with Concurrent Mode, React Suspense and Error Boundaries](https://github.com/meteor/react-packages/pull/271#issuecomment-518414448). - I wrote new TinyTests for the hook, and ported back the old ones. - Above #271, this PR fixes a number of issues raised in that PR. - It also switches the underlying deps compare functionality from a fork of React internals to using `useRef`. There was some concern that results from that may be randomly tossed, but for now (react 16.8.6) they are stable. Even if they are tossed, the only effect this will have on our implementation is that it'll recreate the computation on the next render. - This PR also adds a third param to the hook, which is a computation lifecycle hook. This method is structured like the method passed to `useEffect`. The main function runs when a new computation is created (before `reactiveFn`) and then if it returns a function, that function is run right before the computation is destroyed. I don't know if this is really all that useful in real world use cases, but it is useful for testing some internal behaviors. I left it undocumented for now. - This PR also now passes a reference to the current computation to the `reactiveFn`. - Compatible with SSR. Since this bumps the react version requirement to 16.8, there has been some discussion about how to properly release this with a major version bump. One suggestion was to bump the old version to 1.0.0 which can receive updates separately, then release this update as 2.0.0. I believe this is ready for review. (Third time's a charm!) CC @hwillson @menelike @yched

github.com/meteor/meteor

Release 1.8.2

meteor:master ← meteor:release-1.8.2

opened 04:40PM - 10 Apr 19 UTC

benjamn

+8022 -5104

Meteor 1.8.1 has been released and recommended 🎉 🌮 💫, and (as always) the outsta…nding issues/features fall into two categories: * those we can fix/implement by releasing updates to Meteor packages ([Package patches](https://github.com/meteor/meteor/milestone/40)), and * those that will require a follow-up Meteor release, because they involve changes to the `meteor/tools` codebase (including the dev bundle), or because they involve significant changes to core packages that we want to avoid releasing until the next Meteor release. Meteor 1.8.2 (this PR) will bundle up any urgent bug fixes or minor improvements that require a new Meteor release. Feel free to target the `release-1.8.2` branch instead of `devel` with any PRs that seem to fit this description, or we can help you make that decision if you're unsure. As anyone following Meteor development recently will realize, community input matters a LOT when it comes to deciding what goes into a release, and when it's time to stabilize/finalize it. We welcome that input, and we will do our best to release Meteor 1.8.2 as soon as it's clear it solves specific real problems for Meteor developers. There will also soon be a Meteor 1.9 pull request for more experimental changes, such as (potentially, but not limited to) upgrading Node.js. Let us know if you think we've mistakenly put something into the [1.9 Milestone](https://github.com/meteor/meteor/milestone/65) that belongs in 1.8.2, or vice-versa!

There is a lot of small and simple ones for which a quick review should be enough to get them merged. For example:

github.com/meteor/meteor

Chore: Use https in readme

meteor:devel ← imba-tjd:patch-1

opened 03:30AM - 09 Oct 19 UTC

imba-tjd

+2 -2

github.com/meteor/meteor

change success variable declaration

meteor:devel ← gabrielmcoelho:patch-1

opened 04:07PM - 15 Oct 19 UTC

gabrielmcoelho

+1 -1

Since variables defined with **const** are not supposed to be reassigned, 'succe…ss = false' could cause errors. Changed declaration to **let** to avoid that.

etc.
I think these small ones should be quickly merged/closed (and also in the future), so that the clutter does not obstruct the more important/complex big ones. After that the next step should be all the Typescript conversions (before or after 1.8.2 release, does not matter).

menewman · November 5, 2019, 6:34pm

Although I absolutely agree that functional changes should take priority, I would like to add a +1 to reviewing TypeScript conversions (after 1.8.2 is fine). As someone who submitted a few conversion PRs, I kind of lost steam when I had a few PRs that had been hanging out for a while without review, but I’d love to jump back into it if this is still an initiative that Meteor wants to move forward with.

afrokick · November 5, 2019, 10:08pm

Especially with new TypeScript 3.7

seba · November 7, 2019, 2:47pm

I just went over all of them, and all of them seem to still be valid. Of course, for the ones more than a year old, it might be hard getting in touch with the submitter for changes.

coagmano · November 8, 2019, 3:02am

I’m still just waiting for this :lolsob:

afrokick · November 8, 2019, 10:32am

@benjamn answered about it https://github.com/meteor/meteor/pull/10498#issuecomment-551541755

I would love to see that merged, but the test failures indicate that the major version bump (to jQuery 3) is causing version solver conflicts. This is no surprise, since packages that depend on jquery almost certainly need to be updated to work with jQuery 3 instead of 1.12.1 (or maybe they can stop using jQuery entirely), but I’m not sure how much work that will take.