sounds good, I will keep looking in to why the login button becomes non responsive at times too
I pushed up the update i made to get the showPrivateButton field to work properly (with a more acceptable design)
So the LoginTemplate freezing up periodically is the only thing left to solve
It looks like a bug in my package that occurs when autorun is called inside onMount (in this case inside Blaze). Iāll look into a solution.
I pushed version 0.2.1 of rdb:svelte-meteor-data which has a stopgap fix for the unresponsive Blaze template bug. Iāll continue to look for a more comprehensive fix.
seems to have cleaned up that issue. if it comes up again I will let you know. Thanks for the bug fix
I pulled down your code to play around with it. Looks good with the updates. The only issue Iāve encountered is when I create a new user I see the error username already exists. Are you seeing the same?
I also extracted currentUser so that I could import it into any .svelte file which feels kinda handy.
Curious, if anyone is aware of any downsides to this approach of setting up tasks as opposed to setting up the empty array and filtering:
$: tasks = hideCompleted ? Tasks.find({ checked: { $ne: true } }, { sort: { createdAt: -1 } }) : Tasks.find({}, { sort: { createdAt: -1 } });
Did you update to version 0.2.1 of rdb:svelte-meteor-data that I pushed just an hour ago?
I think that approach to filtering is fine. It may even be slightly more efficient than doing the filtering inside a reactive computation.
I just finished the first version of a Blaze integration paackage:
As soon as @zimme sets me up with access to the svelte org on Atmosphere I will push it there, and you will be able to pull it in and just do:
<script>
import { BlazeTemplate } from 'meteor/svelte:blaze-integration';
</script>
<BlazeTemplate template="loginButtons" />
The package also supports reactive data updates, but you wonāt need it in your use case. I plan to further extend it to support slotted content as well as allowing Svelte components to be rendered inside a Blaze template.
Yes. It looks good from my minimal testing. 
Not sure if the Username already exists bug that Iām seeing is related to your package. I see the error right after the account creation is successful.
Cool. I just pulled it into my project. Iām seeing a Can't find variable: Template on BlazeTemplate.js:9
my only comment on that way of doing it is it may be a little terse for someone that is a beginner. Cause the simple-todo tutorial is meant as like an introduction to Svelte and Meteor and then in step 12 of each tutorial we will be directing people to more advanced material on the framework you are working with. I know step 12 is kind of bare now, but that is the long term vision i suppose.
With that said if we want to make that change I am happy to do so.
thatās great. I will update the code once I am able to do so. thanks for your everyoneās help with this
So next up on my to do list is going to be to make a pull request for the Guide that outlines Svelte and how to use it with Meteor and what packages are out there.
I was thinking about making a svelte skeleton for the meteor create command but then we need a vue one, and we already have a few ā¦ and we have the example repositories you can create by running meteor create --example todos for example and those repos are basically abandoned. So i am not sure if that idea needs to be rethought.
Makes sense. I could see how the ternary could trip someone up. I was mainly interested if anyone was aware of any benefit / downside of using the cursor vs the array. I seem to remember when I was learning Blaze that people recommended using the cursor because it was more efficient for Blaze. Not sure if that is the case with Svelte and @rdbās package or if it doesnāt really matter.
One thing that does seem important as a best practice for the guide is @rdbās note here:
I think that would also mean that you could remove passing in key since itās not used in the Task component and your #each block would look like:
{#each tasks as task (task._id)}
<Task
task={task}
/>
{/each}
OK, my Blaze integration package is up:
https://atmospherejs.com/svelte/blaze-integration
Just pointing this out since fell into this trap too: I have discovered that just passing in the object directly into the component causes Svelte to rerender all the Task components when a single task is added, because Svelte refuses to compare objects. You should instead destructure the task and pass in the individual members, or pass in the string ID and fetch the task details in the Task, or you can mark the Task component as immutable (but then it wonāt respond to modifications).
You have to meteor add templating, which you need to have to be able to have Blaze templates to begin with, I think.
EDIT: I added templating as a dependency.
FWIW, I did an update to the svelte:blaze-integration package, now it supports rendering Svelte components inside Blaze templates as well. This will surely be useful to people who are incrementally migrating an existing application from Blaze to Svelte (like myself). It may be useful to touch on this briefly in the guide.
Ah, thank you for clarifying. I did some more playing around and keyed each blocks arenāt enough as youāre saying. Youād need both the keyed each block and one of the options you describe. Another option would be to spread the props:
{#each tasks as task (task._id)}
<Task {...task} />
{/each}
I guess the main downside here is if you pass over props that arenāt explicitly named in the child component, svelte gives you a warning.
The cleanest one imo is marking it as immutable though there may be downsides here that Iām not aware of.
Regardless, I think it would be helpful to mention this in the guide. Maybe itās in a performance / optimization section.
The unfortunate thing is that the immutable flag is all-or-nothing. It has subtle implications for all the internal properties too. There is no way to mark a single prop as immutable in Svelte right now. Also see this Svelte issue that I raised about this.
The spread syntax can be a neat way to deal with it, as long as you also use a fields specifier in the MongoDB query so that you only fetch the fields used by the Task component.
If anyone wants to go give the svelte tutorial a try https://www.meteor.com/tutorials/svelte/creating-an-app
and report any issues here https://github.com/meteor/simple-todos-svelte/issues
My computer is at Apple rn for repair, but right when it gets back, Iāll start recording and releasing the video tutorials on my YT channel and will largely follow this tutorial exactly