Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$.fetch data stringification is too simple #128

Closed
dzek69 opened this issue Dec 15, 2015 · 9 comments
Closed

$.fetch data stringification is too simple #128

dzek69 opened this issue Dec 15, 2015 · 9 comments

Comments

@dzek69
Copy link

dzek69 commented Dec 15, 2015

$.fetch('tests/ui.php', {data:{test:{'a':1,'n':2}}})

results in server getting weird string:

 [GET] => Array
        (
            [test] => [object Object]
        )

and

$.fetch('tests/ui.php', {data:{test:[1,2]}})

causes comma separated values:

[GET] => Array
        (
            [test] => 1,2
        )

jQuery results (from $.get, same params syntax) are as expected:

[GET] => Array
        (
            [data] => Array
                (
                    [test] => Array
                        (
                            [a] => 1
                            [b] => 2
                        )

                )

        )

and:

[GET] => Array
        (
            [data] => Array
                (
                    [test] => Array
                        (
                            [0] => 1
                            [1] => 2
                        )

                )

        )
@dperrymorrow
Copy link
Collaborator

would you be willing to start writing some tests for $.fetch?
i have an example of a testing strategy here #130

@dzek69
Copy link
Author

dzek69 commented Dec 15, 2015

sad to say, but i've never do any tests and xhr tests sounds like more trouble than to test a simple function :(

@LeaVerou
Copy link
Owner

Yeah, currently it does very simple serialization, it's not intended for nested objects. Is this useful/common? If so, I can look into adding it. If not, what jQuery does is not relevant. We’re not trying to emulate jQuery here.
While I'm at it, perhaps we need to remove the serialization code from $.fetch() and have a separate helper to serialize objects in custom ways. Need to make sure this won't add more bloat than it's worth though.
Thoughts, everyone?

@dzek69
Copy link
Author

dzek69 commented Dec 15, 2015

For me it's extremely useful. Imagine something simple as:

Fav colors:
<select multiple name=colors>
<option>green</option>
<option>red</option>
<option>blue</option>
</select>

Then I select two items, for server side code it would be totally weird not to receive an array here, but comma separated values. What if I want to have comma separated value in my select?

If simple example doesn't convince you:

Imagine a web application where I'd like to create an invoice. Well, I have one, and while I'm rewritting some parts of UI - I'm implementing Bliss.

[Some "single" stuff, like receiver name, VAT ID, date of issue etc]
Stuff I sold:
<button>[+] add item</button>
<div class=item>
<button>[-] remove</button>
<input name="item[][name]" value="something i sold" />
<input name="item[][price]" value="1337" />
<input name="item[][amount]" value="5" />
</div>
<div class=item>
<button>[-] remove</button>
<input name="item[][name]" value="something else" />
<input name="item[][price]" value="10" />
<input name="item[][amount]" value="1.5" />
</div>

I've already done the parsing of names like item[][amount] and I don't think it should be Bliss problem to prepare such data (document.forms should do this automatically too btw, but in my webapp for some reason I'm not using this).

But sending nested objects data is a must-have for me. Without this fetch seems to be useless on webapps.

(And yes, I can just pack it up into a single JSON and unpack it on the server, but why we are having multiple form items if not for sending multiple values separately? Also if I'd like to use some external API, where I cannot modify server-side code - I'd not be able to use Bliss do communicate with API)

@StrongRef
Copy link
Contributor

It would be nice to move the serialization part away from fetch.
Since different projects have different requirements, perhaps built-in support for a simple, straightforward serialization but with the possibility to add your own implementation.

@LeaVerou
Copy link
Owner

Now that we have hooks (see c8ede04 ), I’m thinking about removing the object functionality altogether and just adding a hook there so that people can handle o.data in any custom way they want.
This way, we could have a plugin that does what the OP wants, and keep Bliss lean :) Thoughts?

@praveenpuglia
Copy link
Contributor

Sounds great to me! We don't wanna be gigantic-we-do-it-all library. :)

@dperrymorrow
Copy link
Collaborator

polyfills and user customization for the win, this ain't JQuery

@LeaVerou
Copy link
Owner

Awesome. I’ve done that in 1f2233a. @dzek69 now you can publish a plugin that does this very thing! (soon we'll have an official plugin catalog too, see #125 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants