Disable Laravel Spark Teams on registration

I am using teams as "servers" for https://captifi.net. I wanted to remove the name requirement from the sign-up form so that the user only has to input their email and password to sign up. I couldn't figure out how to really remove the team name since it is needed in order to be referenced in Spark, so instead I set a variable in Vue to default the server name to "Server Name" and the user can change later after signing up. Removed the name input from the form and it worked. Same with the user's name, I defaulted it to "Name" so that they can sign up without it and change it later.

Under resources > spark-components > auth > register-stripe.js:

Vue.component('spark-register-stripe', {

    mixins: [base],
    data: function () {
  return {
    registerForm: {team: "Server Name", name: "Name"},

  }
}
});

I'm not sure if I understand correctly, and my memory is already a bit hazy from when I did the install, but here goes:

Did you build with --team-billing?

If so, then perhaps it's just a case of removing the Laravel\Spark\CanJoinTeams trait from your User model

@RCHASE - Thanks I will try this.

@KEL_ - Sure. But the problem is that you kind of must go all in either of teams or not on sign up.

I want the team features (not fun to add this later), so I have installed with --team-billing.

But in a dream scenario, I don't want a new user required to create a team on registration (kind of confusing for some new users). Instead, I would like the users to be able to create a team later if he or she needs it. Like how it works on GitHub today.

If you disable the CanJoinTeams on the user model you will not have the ability to create teams at all.

Ahh, I see!

I did look into this a bit and the teams bit of Spark is quite complex, I didn't fancy changing anything at the time, there's much more to Teams than meets the eye.

In itself it might be okay, but it's all the logic for your application too, do you write your access based on Teams or Users? Writing code to check for both use cases is going to make it even more complex.

I agree it would be nice to have teams as an optional extra rather than an all or nothing thing.

What about not worrying about it too much and just assigning default team name like Solo - Team Solo is an oxymoron if ever there was one but it kinda makes sense!

Or, what about changing the templates so the team stuff is still in the back ground but hidden. you could update the Teams page of the settings section to have an on off button that your templates could reference to conditionally hide things. Behind the scenes the user is assigned to a default team which they switch from should they decide to activate teams and create a team? They need never know they are part of a team. The more I think about it the more I think this is the way I would go - I would at least try.

@KEL_ - Thanks for the heads up regarding the complexity. Sounds likely.

At this early stage, I am basing the code around teams and team-ids. Adding this relation in production could be quite hard.

So I have thought since I wrote the question and I agree, creating a team in the background somehow must be the w​ay forward.

Thanks for your input, I appreciate it!

Cool - and you're very welcome - I must admit it I am being a little selfish ;)

I would really like to get a bit of a Spark collective going, it seems to me that this is a fantastic starting point for any SaaS application and it's let down a lot by lack of support/documentation/tutorials. You really need to know what you're doing before you can use it as, apart from the few things that are there and of course this forum, you really are out in the cold.

I don't want to be critical, rather, I want to encourage sharing and collaboration so we can all find out how best to use this thing.

My top recommendation to get going with Spark, if you already have the Laravel skills, is to learn Vue 2, there's a great Laracasts series on this that will reveal a significant amount of what's going on in Spark.

p.s. and if ou don't already know Vue 2 it will change your appreciation for Javascript forever - it's ace!

@KEL_ - Good idea, there should be Spark collective going. :-)

I am still in the early stages of Spark, but if everything goes well I will invest a lot of time. My findings so far are I think people have been too critical about Spark, but the lack of community activity, documentation, old examples (most from 2016), and lack of more advanced tutorials here on Laracast does no make it better.

Agree that you need to know what you are doing (and why is Spark using inline templates?). I have done all the Vue-courses here and just halfway thru Adam Wathan's course too.

Also, I am happy that I went with Vuex from the beginning. I am converting a rather complex jQuery application with a lot of states.

Excellent - I think you might be the first person to join the Spark Collective :D

I have no idea what form this collective will take, but lets see how it goes. At the moment all I do is I check in every day in the Spark section of this website and see if there is anything I can help with, even if my answers aren't that definitive I figure it's got to be better than whistling wind and tumbleweed and perhaps we can work out a solution together. I figure this is a good start.

I agree about the criticism of Spark and the level of support for it, it's wholly justified, but I am the kind of person who always thinks it's better to do something and make a change than to make complaints. Not judging, each to their own, but I have to do what I have to do too!

Yes, I am very new to Spark too, but getting a handle on it reasonably quickly I think.

I believe inline templates are for when the html is not a small snippet that can comfortably sit in your Vue component in a template:, as I've been digging around Spark it's fairly easy to see why some of them are so large. I don't mind it, it works fine and I personally prefer keeping large chunks of html out of the Vue components. If it is something really small, like two or 3 elements, then okay... after that it feels a bit gnarly to me. Have look at the Spark Forms - I would not want all that code in my Vue js file!

@jmac Did you ever come up with a solution to this? I have the scenario of having individual users registration along with teams and have the ability to choose when signing up. Any insight would be greatly appreciated.

@THEMASTERPAGE - Sorry, the project is kind of on hold and I have not investigated this further.

Actually, I have been tempted to go with Nova instead since the onboarding flow seems not so customable in Spark.

But if you find a solution please us know!

Based on @rchase I built a workaround that is kinda ugly but works for me: immediately delete the team after registration if it was created recently. The user will then see the "You have no team yet" screen in his dashboard and can create a team there.

--> make column "name" in table "teams" nullable

/app/Providers/SparkServiceProvider@booted

Spark::swap('CreateUser@validator', function ($request) {
    return $this->baseValidator($request);
});

/resources/views/vendor/spark/auth/register-common-form.blade.php

Hide Team field by replacing lines 4 and 18 with:

<div class="form-group row" v-if="false">

New listener: /app/Listeners/RemoveCreatedTeam.php

<?php

namespace App\Listeners;

use Carbon\Carbon;

class RemoveCreatedTeam
{
    /**
     * Handle the event.
     *
     * @param  object  $event
     * @return void
     */
    public function handle($event)
    {
        // using ->wasRecentlyCreated unfortunately does not work because it's a redirect
        if($event->user->currentTeam->created_at > Carbon::now()->subSeconds(5)) {
            $event->user->currentTeam->delete();
        }
    }
}

/app/Providers/EventServiceProvider.php

'Laravel\Spark\Events\Auth\UserRegistered' => [
    'App\Listeners\RemoveCreatedTeam',
],